Posted
Jamstix, while hosted inside the Audio Engine, appears to have a problem loading its kit sounds.
When loading a kit, I just get the "99 sounds missing" error message. I turned on the debug logs to see what might be happening.
I am suspecting that maybe there is something going on in the engine that may be preventing the plugin from accessing the file system properly?
When hosted inside a Drone - no problem. This only happens in the engine.
---------
here is an excerpt from the (huge!) debug log that the Jamstix instance created.
When hosted in the Engine:
<7.4> Loading sound "Kick - 22'' JS3 Tight"...
<7.4> Sound files are missing for "Kick - 22'' JS3 Tight"
<7.4> Loading sound "Snare - 13'' JS3 Deep CS"...
<7.4> Sound files are missing for "Snare - 13'' JS3 Deep CS"
<7.4> Loading sound "Snare Offset - 13'' JS3 Deep CS"...
<7.4> Sound files are missing for "Snare Offset - 13'' JS3 Deep CS"
<7.4> Loading sound "Ride - 22'' JS2 Paragon"...
---------
and when in the drone where it succeeds:
WS DISK LOAD 0 C:\Program Files (x86)\jamstix3\data\Sounds\Kick - 22'' JS3 Tight _s01.rzd
<5640><18.8> PPQ:0 1:1:0 [0] WS-LDD GM=133184
<5640><18.8> PPQ:0 1:1:0 [0] WS DISK LOAD 0 C:\Program Files (x86)\jamstix3\data\Sounds\Kick - 22'' JS3 Tight _s02.rzd
<5640><18.8> PPQ:0 1:1:0 [0] WS-LDD GM=133184
<5640><18.8> PPQ:0 1:1:0 [0] WS DISK LOAD 0 C:\Program Files (x86)\jamstix3\data\Sounds\Kick - 22'' JS3 Tight _s03.rzd
<5640><18.8> PPQ:0 1:1:0 [0] WS-LDD GM=133184
<5640><18.8> PPQ:0 1:1:0 [0] WS DISK LOAD 0 C:\Program Files (x86)\jamstix3\data\Sounds\Kick - 22'' JS3 Tight _s04.rzd
<5640><18.8> PPQ:0 1:1:0 [0] WS-LDD GM=133184
Mon, 2011-12-12 - 16:42 Permalink
The engine sits in a different directory than your DAW, which will break relative filenenames if you swap presets between engine and DAW drones (copy/paste). Therefore filenames should always be absolute, including the drive letter.
Otherwise I have no idea how this could be related to the drones or the engine.
Mon, 2011-12-12 - 16:45 Permalink
Ah, and in case you are using a 32/64 bridge or something similar, there may be problems accessing the bitness-specific directories on Windows ("Program Files (x86)" is inaccessible for 64 bit programs, "Program Files" points to "Program Files (x86)" for 64 bit programs, etc.) I don't remember all the details, but there is a lot of "magic" going on behind the scenes.
This is an issue with the plugin.
Mon, 2011-12-12 - 17:30 Permalink
Yeah, I'm pretty convinced that it is a problem with the plugin, and I plan on eventually reporting the issue to Rayzoon.
However, the peculiar thing is that it DOES work in the drones, that's why I wanted to bring it to your attention. There could be some unexpected behavior happening on the Synfire side and I want to rule that out.
Also, in the case where it doesn't work, I am not using a DAW at all (pure Synfire engine only), so the location of the engine compared to the DAW doesn't apply.
(No bridging is used by the way. Using 32-bit all the way in this case.)
Mon, 2011-12-12 - 17:54 Permalink
... ("Program Files (x86)" is inaccessible for 64 bit programs, "Program Files" points to "Program Files (x86)" for 64 bit programs, etc.) ...
Only partially true. The second half of your statement is true. If a program asks for the location of the "program files" directory through environment variables, then 32-bit and 64-bit processes will yield different results.
However, neither is prevented from accessing the other architecture's Program Files if addressed through the file system by name. It is quite common to do so in the case of VST plugins.
Mon, 2011-12-12 - 18:16 Permalink
I don't remember the details exactly, however it is extremely tricky for 32/64 bit programs to access the other architecture's directories. Windows performs string subsitution on the paths you give it without asking.
I had to resort to using "C:\Windows\sysnative\..\..\Program Files" in order to find and launch the 64 bit audio engine from 32 bit Synfire, because 'C:\Program Files' is always substituted by 'C:\Program Files (x86)' and you cannot do anthing about it. Google for sysnative and you get an idea of how quirky all this is (and, hey, of course 'C:\Windows\system32' is for 64 bit executables ;-) )
Mon, 2011-12-12 - 18:57 Permalink
OK, you may be right when it comes to launching programs in the opposite architecture*.
But when simply accessing the directory through the file system, to read data files, Windows doesn't perform any substitutions. It's just treated like any other directory.
*As a side note, I trust you that it is quirky. If the whole process to get this working was convoluted and unintuitive, then you must have done it right. Heh. If it were straightforward and simple, I'd be suspicious. It's Microsoft. :-)
Mon, 2011-12-12 - 21:37 Permalink
I did, just before I made the last post. :-)
Just tried it again from a 64-bit application just to be sure.
(Again, without using environment variables or API calls to construct the path. I just used a string-literal for the full path. No substitutions happened.)
Maybe something in the runtime you are using is doing the substitution?