This is my first question after leeching over here for some time.. So spare me.
I need to apply the iZotope Vinyl VST effect to some audio files via CLI or C++ (so language doesn't really matter), it has to work on a Mac or on a Unix based system. I've researched all over the webs and can't find any working solution.
I've tried using MissWatson, a command line utility, this works but my result audio files are silent...
./MissWatson -plugin=Vinyl -input-file="/Users/Sjaq/Desktop/test.wav" -output-file="/Users/Sjaq/Downloads/MissWatson-v1.0-mac/res.wav" -parameter=1:0.6,2:0.6,11:0.4
Then I tried using the Steinberg VST SDK by creating a host application, starting from the vstvalidator provided by the SDK. But when I try to load the VST I get this error:
2010-12-01 16:57:40.774 vstvalidator[4654:903] Error loading /Library/Audio/Plug-Ins/VST/Vinyl.vst/Contents/MacOS/Vinyl: dlopen(/Library/Audio/Plug-Ins/VST/Vinyl.vst/Contents/MacOS/Vinyl, 262): no suitable image found. Did find:
/Library/Audio/Plug-Ins/VST/Vinyl.vst/Contents/MacOS/Vinyl: no matching architecture in universal wrapper
And I don't know what to do. I'm pretty new to C++ and and made a few apps without any issues, but this time I've hit a dead end.
I've read about pyvst but it seems to need a DLL for the VST so that didn't work either.
I'm the author of MissWatson, and as you probably noticed on the webpage, I unfortunately was required to close-source the code, so I can't really ask you for more diagnostic information, since I wouldn't be able to patch MissWatson if it's a bug there. However, I would recommend running MissWatson with the -verbose switch and perhaps logging that output to file if that floods your terminal. You might find something in that output which helps you to diagnose the problem.
Anyways, as for the error in your VST host, I have a feeling that you are compiling your app as a 64-bit executable and trying to load a 32-bit plugin. Since hardly any VST/AU plugins (and also sequencers, for that matter) have made the leap to 64-bit, you'd be better off just compiling your app as a 32-bit x86 binary.
By default, the "debug" configuration in Xcode only builds your app for the native architecture of your machine to save time during compilation. I would advise that you disable this feature in your project's build settings and always build with the architectures you plan to ship with. This will prevent weird cross-architecture types of errors like the one you saw above.
Edit: I have since started a new command-line VST host to replace MissWatson which is called MrsWatson. You should try using this tool instead.
Perhaps you can port the source code of this open source vst host to match your platforms?
http://www.hermannseib.com/english/vsthost.htm
Scroll down to the bottom of the page.
Hope it helps.
Related
I'm a newbie at maya c++ API making.
I made a byte of maya c++ api to my computer with Visual studio.
My .mll filetype worked well on my computer with devkit using mel(loadPlugin ~~).
But when the code is run on other computer, it doesn't work. I get the error:
//Error: line 2: Unable to dynamically load : C:/Users/user/Documents/maya/2018/scripts/outOfcameraAPI.mll
Someone told me to bring the dll file to other computer, but I can't understand yet.
I'm sure this is very easy to fix for someone but it is making me crazy. If somebody who reads this knows how to fix, please let me know. Thanks for reading.
These types of error have two reasons in most cases: 1. Build in debug mode, not release mode. Debug mode will rely on debug libraries which are only available if the development environment is installed on the computer, e.g. VisualStudio. 2. The plugin needs an additional library, e.g. a alembic reader will need the alembic library.
I am developing my QT application on windows 10 . The development is complete (as for now).
After run the application in debug mode from QT-creator, I am trying to run the executable from the build directory. But it shows me an "Application Error" dialog with the following message:
The application was unable to start correctly (0xc000a200). Click OK
to close the application.
What is the problem and How to fix it ?!
The error codes are given to you in the error message for a reason. They don't mean anything to regular users, but we're programmers and we are the intended audience. Now that Google has been invented, you have absolutely no excuse for not taking the 5 seconds to Google the error code and see what it means.
In this case, 0xc000a200 is an error code that corresponds to STATUS_NOT_APPCONTAINER. The master list of COM error codes is in the Windows SDK headers, specifically ntstatus.h. If one looks this one up, one sees the following description:
This operation is only valid in the context of an app container.
Now, admittedly, once you get to this point, you may discover that you are in well over your head. You may not have any idea what an app container is, and certainly no clue about how to fix it. But at least then you would be able to ask a good question, which will go a long way to getting you a good answer.
But let's see if you can get lucky this time anyway. This error is most commonly encountered when an application that is not inside of an app container tries to load a DLL that is marked as being part of an app container. It is the linker that is responsible for marking a DLL as being or not being part of an app container, controlled by a series of options for whatever linker you're using. On Microsoft's linker, it is /APPCONTAINER:YES and /APPCONTAINER:NO that control this. I'm not sure what toolchain Qt Creator uses, but if it is not Microsoft's, this should at least get you started looking in the right place in that linker's documentation. Make sure that all DLLs used by your application are not being marked as part of an app container.
The option should be off by default for a regular C++ desktop application project, but it's possible that one of the DLLs started out life as part of a Windows Store app. Or it's possible that the switch just got thrown accidentally.
I had the same error, but the approved solution wasn't the cure. What I found is that I had installed the wrong Qt compiler support packages. For me it was Qt 5.9.1 on Windows 10 64 bit to use with Visual Studio 2017. When installing Qt I selected the "msvc2017 64-bit" option. Sound good, right? Wrong: what I wanted was the "UWP x64 (MSVC2017)".
I'm working on a multi-platform project that is composed of a service/daemon which runs on Windows, Linux, and Mac OSX.
The code I have is portable, and the application runs fine (from the command line) on all the systems. As this application is designed to run in the background, I made it a Windows service on Windows and a Linux daemon (with the appropriate scripts in init.d) for Linux.
Now my problem is Mac OSX: I have little experience with this operating system, and I am having hard times figuring out the best practices for it regarding my situation:
I'd like to have an installer for my project (I believe a .dmg file, that would likely install an .app; please correct me if there is a better alternative).
Here some information about this project of mine:
It is build entirely in C++ (it uses boost, curl, iconv)
The current build system is not XCode (however If there is a way of keeping my current code layout while integrating and building everything into XCode, I don't mind. I've done something similar for Windows anyway).
There is no graphical user interface
The daemon should start on startup automatically (or even better: make that a user's choice).
The daemon requires root access during its execution.
That's probably a lot of context to consider for a single question, so I will try to make it easier to read:
How would you package/create an installer for a pure-C++ daemon on Mac OSX ?
Since this doesn't have a UI, I wouldn't package it as a .app -- that's the preferred format for double-clickable GUI apps, not for daemons. If it's just a single binary (no support files except maybe things like config files, etc), I'd follow unix conventions and put the binary someplace like /usr/local/libexec (or wherever you put it on Linux). Note that /usr/local doesn't exist by default on OS X, so your installer will need to create it if it doesn't exist.
For getting it to execute: I'll agree with James Bedford's suggestion of using launchd. The launchd .plist file should be installed in /Library/LaunchDaemons (LaunchDaemons run as root at startup, while LaunchAgents run as normal users when that user logs in). Make sure the daemon does not drop itself into the background -- launchd keeps watch over the programs it launches, and if they background themselves it thinks they've crashed, and generally tries to relaunch them, which doesn't work very well. You can adjust the settings to work with background programs, but it's best to have it run in the foreground.
For packaging: Here, I agree with mah -- use an installer package. I actually still like the old GUI PackageMaker tool (deprecated, but it still works), but the new CLI tools are probably better to learn at this point. If you follow my recommendation about /usr/local/libexec, your package should actually contain the "local" directory (with libexec subdir and your binary in that), and install that into /usr -- if /usr/local already exists, it'll just merge with what's already there, but if not it'll create the entire thing. On the other hand, /Library/LaunchDaemons is guaranteed to exist, so your package only needs to contain the actual .plist file to put in it.
Packaging as a .app makes some sense if what you're distributing is more than just a command line (for example, if it has resources such as static configuration data, images, frameworks/dylibs) that need to come along with it).
Regardless of what exactly is getting distributed, you can create an installer using tools that you already have -- pkgbuild and productbuild, both in /usr/bin. Making OS X Installer Packages like a Pro - Xcode Developer ID ready pkg can get you started using these tools.
Have you checked out the Daemons and Services Programming Guide provided by Apple? I think that would be very helpful as an introduction to the platform and should point you in the right direction (if not show you how to do exactly what you want).
You should also check out launchd (which is discussed in that programming guide). launchd is the official deamon launcher/manager for OSX, and is heavily integrated with the operating system. It should be easy enough to wrap your existing cross-platform deamon into a launched deamon, and you can integrate with OS X so that the deamon will start up automatically.
I have searched and found no answer to this
I have a weird problem when running executables through developer studio (2008): a basic 'hello world' exe works OK when created through the usual dev studio project creation mechanism, but when trying to run a library based program the software crashes with STATUS_BAD_NETWORK_PATH. The program uses Qt and zlib behind the scenes and is written in C++, but (as far as I'm aware) is not dependent on any particular network locations on initialisation; we do have Sophos installed on the PC too.
The weird thing is that one cant even step into the main: the program fails well before this with the error. If we plug the network in, it starts up just fine ... The odd thing is this only occurs on a specific 64 bit Windows 7 machine.
Does anyone have any tips as to how to trace where the issue is? We've tried tracking using procmon but it is not very revealing; no obvious failures up to the point where the program crashes.
We have now figured out the answer. It transpired that there were 2 issues:
Firstly a wrapper .bat script that was launching developer studio was setting the PATH environment variable: a location in this path was being specified using a UNX style path (e.g. \\a\location\somewhere) rather than a mapped drive. The executables were not actually using this location but when the network was unplugged this it seems that this was disrupting things from dev studio
This, in tandem with a network configuration error on the PC, meant that deep down in the runes, something was failing.
So - advice if you see such an error
Check your PATH and make sure it is sensible
Look in your PC's configuration logs, and see if you can see any networking issues
...
I created application which uses wxWidgets library using visual studio 2008. Now I would like to create version which may be run on other machine.
Because right now when I want to run It on another machine there is an error:
the application failed to start because its side-by-side configuration is incorrect.
What can I do to make It work ?
The Event Viewer should have a record showing what DLL was being searched for, what version of that DLL if found in the SxS cache, and what version it was looking for but couldn't find. You'll then want to (for example) include the correct version of that DLL to be installed with your program. Alternatively, just link to virtually everything statically -- it'll make your executable a lot bigger, but eliminate a lot of problems like this relatively painlessly.