I'm just trying to get my foot inside the OSX world after recently getting a MAC.
Over the past months i haven't successfully built a working VST 2.4 yet. I simply dont get why: the projects in the vst examples work (somewhat) out of the box, but my own projects fail to work.
I've mirrored every build setting exactly (including info.plist and pkginfo), double checked that the contents of the vst.app is identical, correctly gets build as vst with correct extensions etc., and the code is virtually the same, however my vst doesn't get recognized in any of the hosts i tried.
The commandline even is identical for the build.
I've tested my VST with the included minihost vst tester, and it passes and works - but still wont be recognized. I even checked the exported symbols with nm and they look correct (ie. createEffectInstance is correctly exported).
What gives? There must be some hidden build setting somewhere that i haven't discovered that seems to disqualify my VST.
Probably the most obvious but overlooked setting: are you building as 32 or 64 bit? You need to make sure that the bitness matches your host, otherwise the plugin won't be loaded (which, btw, might explain why the plugin could load in your self-built minihost and not another sequencer). To ensure compatibility with most hosts, I'd go for 32-bit build.
Also, here's a tutorial I wrote on the subject awhile back. However, you claim that you are doing everything correct with the Info.plist and whatnot, but perhaps you missed a small step:
http://teragonaudio.com/article/Making-a-VST-plugin-from-scratch-with-Xcode.html
Another potentially useful tool is MrsWatson (disclaimer: I'm the author of that program). It's a command-line VST host which can be used to provide diagnostic information about VST's, and also is designed for plugin testing and debugging. Because of the 32/64 bit difficulties with plugins, on Mac OSX the program ships separate 32 & 64 bit binaries rather than using a universal binary.
You should try running the following command on your plugin:
mrswatson --verbose --plugin /path/to/wherever/you/put/the/plugin.vst --display-info
If you see a list of parameters and other info, then it should be kosher and able to be loaded in most sequencers. Hope this gets you on the right track!
Try using your debugger to watch what Dispatcher() calls your host makes. Check if there are any differences between your plugin and the included example projects. In my experience a host will usually abort loading a plugin immediately after a Dispatcher() call raises an exception or returns a result the host doesn't like for whatever reason.
Related
While working for just one month with the MPLABX5.5 + XC32 3.01 I've already had 3 separate instances where code compiled incorrectly, causing my program to fail after either the stack or frame pointer began using an incorrect address. I would like to dump these tools and try something else as tracking down compiler errors is sucking up too much of my time. Is there anything else available that I can use to work with a PIC32MM? Even access to a different compiler than XC32 might help.
I would like to do the same thing. Maybe we can collect the best options for how to get there, as after many many tries, I haven't yet been successful. As one starting point, I'd also like to be able to recompile xc32-gcc from source to understand exactly what it's doing, and to be able to compile xc32 binaries for other architectures (like, as insane as it may sound, I'd like to compile some code for the pic32mm platform with clang or gcc running on a raspberry pi.)
I would love to be able to even just compile xc32-gcc from source. I know this is possible, but I've not been successful. Some links and starts:
https://github.com/zeha/xc32
This seems to be the most recent grouping of source I've found, but I haven't yet figured out how to compile it.
ChipKit is cited a lot, but, I haven't gotten to the bottom of getting that to build for me either. There are numerous projects here, and I'm not sure how they all fit together yet:
https://github.com/chipKIT32
I suspect somebody (maybe someone who will see this post) knows the formula or script or docker file, or whatever to make this simple.
https://gitlab.com/spicastack/pic32-parts-free
This project seems close to what we're talking about, but, the
recommended way to install is with podman and gentoo. I'm not a
gentoo person (yet?), and the docker version failed for me. It's
probably a simple fix to the dockerfile for a gentoo person, but.. I
didn't get there yet. (I did try installing gentoo and started down
the path but holy cow, talk about being down a rabbit hole when what
I'm trying to do is get a pic cross-compiler working.. when emerge on my new gentoo install failed with a python error, I gave up.)
https://github.com/andeha/Twinbeam
This project also says some of the "right things" about building pic32 code using llvm, and has references to llvm2pic32 in this project: https://github.com/andeha/Sprinkle
I've also not yet managed to get this to make viable intel hex files that I can use on a pic just yet, but there's promise.
Use clang/llvm to generate code. I think it will compile C and generate mips out of the box and I've gotten that far, but I can't get it to link and produce a valid hex file yet. The linker scripts from microchip seem sort of ok, but the hex files end up putting the code in the wrong place, I think. I should probably put together a blinky-light example and try to push it farther, and share it with others to figure out what the deal is, but even stepping one step further back and just trying to get a super simple mips assembly program to get linked and be uploadable to a PIC32MM part would be a great success to me.
Maybe others have better references and links?
My goal is to connect the open-source CBC solver with Pyomo in Spyder. I am working on a Windows 10 machine and it is not an option for me to use the NEOS server due to company policy.
I have downloaded the binaries from Bintray (https://bintray.com/coin-or/download/Cbc#files) that include a cbc.exe file. However when trying to run it, several errors come up stating that I am missing files (among other libbz2-1.dll and zlib1.dll). I do not know much about linux or software development but after a lot of time on google I understand that these are used for unpacking data among other things. I found all files except zlib1.dll in a developer chat on the same subject and zlib1.dll I found on another page. However when running I now get the error: “The application was unable to start correctly (0xc000007b).
I have also tried downloading MSYS2 MinGW and followed instructions from CBC. I don’t know if I require this or if it is only for developers.
Can anyone tell me what to do? I suspect other people than myself want to use CBC in Pyomo as an alternative to GLPK.
If you already have the .exe file, make sure it is in your current working folder (set as the working directory in Spyder, simply opening your file is not enough) and call it using the SolveFactory function:
opt = SolverFactory("cbc.exe")
results = opt.solve(model)
It works for me.
You will find some general information here where i outlined some approaches.
While this was targeted at Clp, it also applies to Cbc.
It's a bit strange as i observed too, that some libs are not statically linked (zlib) while it's certainly doable. But as mentioned in the thread, this should not be the case anymore (see the restriction about which files are fully statically linked) and therefore your observation is strange (and you did not say, which file you downloaded).
So i would trying one of the following (in this order):
Try again with your source, but stick to the master-versions (see first link) as the maintainer only guaranteed fully-static builds for those!
Use the builds from AMPL
(tested and works for me; generally recommended in terms of quality/stability of builds)
Use the builds from coin-or/pulp, another modelling-tool for python
(tested and works for me)
Compile from source using mingw64
(Use any build and provide some external dll of zlib and co -> hard to debug)
Of course i completely ignored other potential issues:
license-stuff (what's part of those builds)
not sure if a company can afford to use binaries not build themself in regards to legal stuff
version-compatibility with python
does every version of Cbc work
cbc version + configuration
modern version
compiled with multi-threading
...
Ok, I went through great lengths but I finally got my integration to quickbooks working on my VB6 application. It works perfectly on my build machine. I actually installed the qbdsk11 on my build machine and worte and tested the code. The ONLY new reference in the project is the QBFC11.dll.
So, I added the QBFC11.dll to my innosetup, told it to do a regsvr on the dll, and hoped this was enough.
NOT.
First, during install, I get a failure to register the dll. Apparently, this DLL isnt meant to be registered?
But the .DLL was put in Windows System32, so I tried my program anyways...
NOPE. Doesnt work. I get a runtime 91, about an object variable not set. Which makes sense, if it cant create the object.
So, for grins, I moved a copy of the .DLL into the program folder, next to my executable.
Same thing. Runtime error 91.
So, i then grab the whole qbsdk11 installer and install it on this machine. I figure I can make it an additional download for people who want to use this extra functionality.
But no, even with the whole SDK installed, I still get the same runtime error.
I have not been able to find any CLEAR information on how to proceed. I'd prefer for this to be part of my base install. But apparently something still just isn't right.
What did I miss? How do I fix this? I don't even know what to try next.
If you're using QBFC11, you must install the QBFC11 redistributable components with your application. You can find instructions on how to do this in the QBSDK Programmer's Guide in the section titled Redistributing SDK Components With Your Application, subsection Using Installers and Merge Modules.
The most likely cause of the runtime error you're currently getting is the manipulation of the QBFC11.DLL that you did before you installed the SDK. I would start again with a clean OS image so that you can get the proper procedure down.
I have a project which has several components loaded by a single preloader swf.
The preloader swf is strictly AS3 (No flex) and uses Loaders to load two different swfs which both use the flex library (Statically compiled, not rsl).
When I compile all three under linux and run the resulting preloader, one of the swfs fails to load properly, and the exception below (at the bottom of this post) is thrown.
If I compile the same component using the same ant task in windows, the component loads just fine without error. The windows file is also 683 bytes smaller.
This is true using the flex SDK 3.2.0 and 3.3.0 under linux and windows.
Have you seen this type of behavior? Can you offer any suggestions for why it might be happening, or how to determine what is wrong?
TypeError: Error #1009: Cannot access a property or method of a null object reference.
at mx.managers::FocusManager/activate()
at mx.managers::SystemManager/activateForm()
at mx.managers::SystemManager/activate()
at mx.core::Application/initManagers()
at mx.core::Application/initialize()
at OC_Footer/initialize()
at mx.managers::SystemManager/http://www.adobe.com/2006/flex/mx/internal::childAdded()
at mx.managers::SystemManager/initializeTopLevelWindow()
at mx.managers::SystemManager/http://www.adobe.com/2006/flex/mx/internal::docFrameHandler()
at mx.managers::SystemManager/docFrameListener()
So wait, are you using different version of the SDK in each platform? That would certainly account for some differences (at the very least in the size of the swf...)
IIUC you get this error when you're loading the page in the browser, right? It's hard to tell from just the stack trace what's wrong, but I can tell you that I used to get a similar error on Windows and it had to do with keyboard events (e.g. using the tab key to move between elements when popups are visible, and similar stuff). Sorry I can't offer a more accurate diagnosis.
I'm not sure I've solved the real problem (Why the compilation was different under different OS's), but I have found that the newer version of the flex SDK does not exhibit the same issues.
I created a bug for the issue here:
https://bugs.adobe.com/jira/browse/SDK-20147
The short of it is, build 3958 (The one default with flexbuilder at the time that I created the bug -- This may still be true) appears to have a number of minor bugs. Upgrading the flex SDK to build 4852 alleviates the symptoms, and I can build projects successfully in a number of environments.
Microsoft distributes source code to reference implementations of their different Direct3D APIs to hardware vendors, driver developers, etc. This code builds using the ever-cryptic WDK (formerly DDK) build system, and virtually never works out-of-the-box. Though widely used, this code is semi-private, so there is never any basic helpful information available on the wider web. This is commonly used enough (and a well-known pain in the ass in this community), and the basic build information insensitive enough, that it should be discoverable on Google.
The build readme suggests using the WDK and building with the command build -cz -daytona. This, confusingly, spits out a bunch of output yet builds nothing.
Getting past this, the Vista with WDK 6001.18002, the latest d3def9 source distribution fails in the link subproject with "failed to produce any output - warning treated as error."
The XP d3dref9.dll can also be confusing to build, frequently failing to find D3D headers and types.
There are generally two major issues quite common in building the refrast source drops as they come direct from Microsoft.
First, the build -cz -daytona command is either a typo or relies on undocumented additional external configuration. Building in this mode parses all the source, but never specifies which platform(s) to build. Since all platform dirs (daytona and win9x), where the actual outputs are specified, are "optional," nothing is ever actually built. The solution to this is to instead use the correctly-specified command build -cz daytona (no '-' on daytona). This should parse the sources and then actually build everything.
Past this, there are usually also problems with the out-of-the-box build setup.
The new WDKs (e.g. on Vista) generally fail in the final linking step with a spurious linker error. This is easily fixed by adding:
LIBRARIAN_FLAGS = $(LIBRARIAN_FLAGS) /IGNORE:4001
to the link/sources.inc build file. After this, build -cz daytona in the root of the source drop should build and link everything out-of-the-box.
On XP, it is also common to have issues if using older DDKs (pre-Windows Server 2003, i.e. "XP"-labeled DDKs). In particular, the refrast project relies on core D3D9 headers existing externally, and these are not included in the XP DDK. Simply using the latest WDKs (rebranded from "DDK" post-XP) solves this. Contrary to the naming, all newer WDKs are generally supersets of older releases, and so include build environments for platforms back through XP.
There may also be issues with some XP refrast source releases including code which triggers more pedantic compiler errors in the newer WDK compiler releases. These, however, can usually be easily fixed by iterative compilation and source tweaking in response to any simple safety/correctness errors raised by the compiler.