Preset Text Replacement for loading? Thoughts please..

trogluddite · 10 Aug 2011

My preferences module uses a system similar to what you describe, though it is a little more complex, as the parameters are given names, which will obviously slow things due to the text parsing.

A few things come to mind from my experience with that module...

1) Array storage - this will never work quite like the VST presets. I don't quite understand how VST presets work inside SM, but importantly, the communication between presets and the manager is bi-directional no matter how deep you bury the VST preset primitives. In contrast, if you decide to make your own system you will need separate wireless links for sending and receiving values. This can be tricky because the wireless links have to be at the correct level in the schematic - you can't get away with burying them deep inside modules like you can with VST presets. For example, in the .osm linked above, if you use an 'INI variable' module to store a custom parameter, the module has to be at the same level as the main module, otherwise communication is lost (in one direction at least). I've suggested before that special 'global' wireless links that operate regardlless of the level would be very useful sometimes - but as yet, we still don't have them.

2) If you need all current parameter values saving within your sequencer file, or VST automation, then you will still need to use VST preset modules to communicate values with the host. Maybe using the preset modules in parallel, rather than in series, with the main data path could enable your custom system to act faster without waiting for the VST preset primitives to update?

3) Assuming you have lots of songs on the go - you will need a way to ensure that the correct patches are loaded at startup for each song - so at least a VST preset for the file path will be needed.

The crux of the problem is knowing whether the slow preset changing is inherent in using the VST preset system, or is it simply a matter of the sheer amount of green/GUI calculating that needs to be done. Most other VST's seem to update pretty fast and without a big CPU spike, so I doubt that it is the VST spec. per se that is the problem. With many of my SM plugins, I've often noticed CPU spikes when changing presets, even when I've done my best to design out any excess trigger activity - a few have even caused audio drop-outs at change time that I just can't seem to eradicate (updating wave displays and big arrays seem to be the biggest troublemakers). So my gut feeling is that the amount of triggers is the biggest problem - for every parameter changed, every consequence of that change has to work it's way through the schematic before the next one can begin to be processed - as the green system seems to have quite low thread priority, it's quite likely that this chain of events gets interrupted quite a lot by other processes, further slowing the interval between triggers. If this is the case, then making an alternative preset system is unlikely to speed things up by very much - the same amount of info would have to be moved around using exactly the same trigger system.

I would sincerely like to be wrong about that! And I'd be glad to help in any experiments we could do to try and tease out and good optimisations.

McBarGig · 11 Aug 2011

Hey Trog, thanks for your answer and nice to see you...🙂 I was speaking with Infuzion the other day on the phone and he had mentioned that you had done a lot of work with trigger blockers. I know in my schem there is probably a gazillion places where I can eliminate some trigger activity and I think that is probably the key to speeding things up. However, I am really not that well versed in trigger blockers. I know what they do, but, it is not apparent where they should be used.

Do you have perhaps have a general set of rules as to some places where they may be placed harmlessly. Like is there any set locations where one would always as a rule of thumb place a trigger blocker. It seems that everywhere I am placing them is at the final consumer of the trigger and it won't go any further anyays, so there is no point in having a trigger blocker. For example, I have a lot of places where I move graphics around, so in those areas I have a trigger switch connected to the redraws, the redraws are only fired once the preset has been loaded and it all happens at once, one time. I have noticed very little change in speed from this so there are other areas where trigger activity must be causing the slowness.

What we need is a good tutorial on triggers and their lifetime. How far can they extend, etc. We usually don't need a trigger to extend itself throughout a schematic, but where is the safest place to kill it?

I can't think of a lot of reasons as to why presets have to load so slow, graphics I can understand, but when you are already blocking redraws, there should be almost no reason for 400 parameters to take 3-4 seconds. So the idea behind creating my own loading technique was to try and alleviate some of this pain..I only need the routine to load values and distribute them, I don't need to save. All the green parsing in SM, forget it...I have found that is absolutely crazy slow, so I do ALL parsng outside of SM with a script or compiled EXE, and with the fact that now you get proper notification that the external process has ended, external processing for parsing is a viable option. Of course it could be that I'm doing something wrong, but I have tried many ways of internal SM parsing and everything I tried has never worked right.. When the preset is saved, it simply runs a routine that parses the file and removes everything except the value so you are left with a list of values only. The GetAt's would simply represent the line number in the file. Now, here's the problem...Triggers...thats what I believe is going to slow it down to a crawl..

trogluddite · 11 Aug 2011

Yes, Infuzion PM'd me yesterday about trigger tutorials - very flattering, hope I am up to the task!

Have some work to do fixing my kitchen the next couple of days - but after that, I'll make a start on putting something together. I suppose it's only fair to point out that the blockers will not fix everything - part of the reason I use so many of them is for the purpose of simplifying trigger order decisions, rather than optimisation per se (probably another worthwhile lesson in itself).

McBarGig · 11 Aug 2011

Yeah its all good info, this is actually one of our last purely SM developments, so after this we'll only be updating existing products but nothing new is planned for SM. We have to start supporting 64 bit as well as MAC so we need to go native. I think Malc and Jorge have done a fantastic job, but, MAC and 64 bit is becoming increasingly important and I am not sure that MAC will ever be supported. I'm sure they'll get to the 64 bit implimentation though..

trogluddite · 11 Aug 2011

Will be a shame to see you both gp 🙁 - but perfectly undestandable if you depend on your plugins for an income.

McBarGig · 11 Aug 2011

haha I feel wanted.. aww Thanks Trog..🙂