Is this really true? I can't seem to load presets/matrices from the Mac on the PC...
The host or the VI Standalone just quits if I try.
J.
The host or the VI Standalone just quits if I try.
J.
-
VI presets from Mac crash PC VI
-
Okay, I'm losing my bloody mind. I've put more time and energy into trying to get the various VSL products working for me than any other piece of software or hardware in my life; juggling around libraries, setting up slave machines, testing hosts, and on and on... But what about a mono option? I remember I used to have mono versions of my old Opus libraries for GIGA, just so I could load up a bigger template, with a good variety of expressions. So why not mono for the VIs? This would presumably cut memory usage by something close to 50%, and would presumably reduce CPU overhead, since the VIs are decompressing on-the-fly.
Thoughts?
J.
-
Now I'm just "jamming" with myself... (sounds bad, doesn't it?)
But you could also provide an "Optimize to Stereo" function, which would run the RAM optimizer, but with the added bonus of expanding the content out to stereo. This way, you could do all your work with the RAM-maximizing mono versions, then when you're finished, just "optimize to stereo" and presto, big and pretty!
I can't wait to hear my next reply...
J.
-
j, there are some things related to the design to consider:
- there is a learn / optimize function which removes unused samples from RAM
- there is a system to not load samples twice even if used in two instances
if you would add now a mono-option (even if it should be possible in the structure of the compiled sample data) this would increase the number of possible combinations (for these options and for each sample) to 8 - wouldn't increase performance, rather the opposite ...
your post sounds if you're currently on a mac ....
did you have alook on your CPU-usage? not too much i'd assume - the biggest part has to be used to render the GUI - thanks to aqua.
christian
ps to stop any discussion before it begins: we will have this fun in VISTA too ... :-/
and remember: only a CRAY can run an endless loop in just three seconds. -
your post sounds if you're currently on a mac ....
did you have alook on your CPU-usage? not too much i'd assume - the biggest part has to be used to render the GUI - thanks to aqua.
christian
Mac and PC. I actually don't really think CPU is the issue, generally speaking. In my case, I'm trying to run Sibelius on the same machine, which is hopeless. And yes, this is thanks (big thanks) to Aqua! I realize that...
Thanks for the response anyway. I just wish there was a way to slim down memory without sacrificing articulations, and without resorting to the memory management system. For some things I just have to work in score; I can't think properly if I don't, and the memory management system is really not convenient for this kind of work. There's too much back and forth with this system... And I tend to work both horizontally and vertically, in roughly equal amounts; compose all instruments for a few bars, move to the next phrase, and so on. Don't get me wrong, I'm sure the optimization approach taken is great for many users, but it just doesn't provide any advantage for me. I need as many articulations at hand as possible.
Anyway, the simple and clear fact that the stereo sample data is compiled in a 'non-channelized' format is reason enough why a mono option can't happen. Fair enough. It was just a thought.
J.
-
I'm not clear how this would affect performance
the player had to decide if possibly a stereo sample is already in RAM when you try to load the same sample in mono. when playing the engine had to look if to play in *stereo-mode* or *momo-mode*. if you press optimize and habe both types of samples in ram - which one to remove? finally if you press the reset-button (reload after optimized) also each possible conflict had to be resolved. such extra-cycles of course would cost something.
the file-stucture - or better the (sample-)data structure: generally all wave data is RIFF. one basic rule for RIFF is that samples for each channel are stored subsequently - so you could create a *new* mono instrument, but not *extract* a mono-information from data representing stereo without a) loading both and processing them or b) store a third *channel* within the file.
christian
and remember: only a CRAY can run an endless loop in just three seconds. -
the file-stucture - or better the (sample-)data structure: generally all wave data is RIFF. one basic rule for RIFF is that samples for each channel are stored subsequently - so you could create a *new* mono instrument, but not *extract* a mono-information from data representing stereo without a) loading both and processing them or b) store a third *channel* within the file.
christian
Right, got it. I do recall that entirely new instruments had to be created for the GIGA presets I converted mono instruments... I guess there's no simple solution. Which is why VSL wound-up where they did! [;)]
cheers,
J.
-
@cm said:
should not ... are you running the same version of VI-software on both machines?
Well I didn't think it should... Yes, same version. I even upgraded both platforms again, just to be sure. Maybe I'll try uninstalling on both machines and re-installing "clean".
thanks, that's good to know.
J.
