DSP Robotics Support

"Preset parameter" primitive can do few correlated things with value, independent from each other. Value:
- can be automated,
- can be stored in presets,
- can be sent to host for automation recording.

Which means, you can automate value, but you don't need to push it through saving/loading routines of the preset system. As it is, my preset loads between 30 and 40 seconds, but it does not matters whether I load single preset or whole bank of 100 presets. So it looks that the redistribution routine slows down.

So the value that you use for automation - you can send separately to a converter, which gathers multiple sources and combines them into one array (sample and hold prims on demand help to reload the array once, only when needed), and then into single string, which is stored via "preset string" primitive. Preset string primitive has no automation, but it stores values on demand.

When I turned off "Preset parameter" from saving values, and redirected values into conversion routine with "preset string" (each can handle 255 chars, so you can combine a lot of values and switches in one string) - preset could load and save rather quickly (I had less than 200 strings to save). But... Things did get complicated under some load. You know, when gui seems to not respond, when too many green calculations are triggered at once. This showed that the advantage of saving via "preset param": prioritization in regards to other flows of triggers. It seems, that FS knows that it must save the preset first, and then can play with other things.

Now - some sub-circuits generate many triggers, so I would carefully approach which and how many of them I connect to array, that is being combined into one string to save.

*

In essence it's like this.

You send your outputs (any format) to converter (sample and hold on input for each parameter in converter, but it would be good to add S&H on output of your sub-circuit too; otherwise when doing modifications, FS may hang a little bit). You latch the S&Hs inside converter, to get the values when you wish to save the preset. You latch the output of array, so that you have only one trigger - after array is made. Array is converted into comma separated string, and saved. Simple.

When you wish to reload your preset, you just load it, and decompile into array. Then you either send the data either via individual wireles outputs or you send a whole array, and in your "value box" you put the "get string at" and place correct index. Then the value is converted to (0-1) range and is sent to "preset parameter", which is responsible for automation. And the circle is completed.

*

I tel how it works in practice after I do the mods.

I suspect it might be good to add a routine, that turns audio (and not needed stuff) off before you start preset saving/gathering that way, and audio on when it's finished. I needed to add such thing (with timed delays) anyway, because without it - my apps almost always crashed.

Well .... as embarrassing as this may be, I'm posting an example of the 'simpleton' method I've been using

Of course, it is because of this that I hope a much better way is shown

Here's a peek at part of the schematic:


Here's the small example


As mentioned ... this example is about as crude as I can get it ... but, it does what's needed ...

But it is 'High Maintenance' [to say the least].

I hope to learn a much better technique ... maybe through the use of the PreSet Manager that I always include in any project.

So ... once the laughing and finger pointing stop ... please take pity on the rookie


Thanks!

I guess nobody tested such things too deep.

Things I would focus on are related to trigger flow; too many unseparated flows = trouble.

Hi tester !

The trigger issue is something I've been now looking at throughout my latest efforts [having been made aware].

In a previous project, using my crude array stacking, save, load ... I have indeed noticed a lag or non responsive situation .... although it did do the job eventually.

In my current project, this entire Save/Load concept needs to be redesigned. I looking closely at your postings, and now to the 'excerpt' you sent. It is much easier to see from your schematic what you were describing earlier.

After just a brief look, I can see the trigger reduction ... but I wonder how that 'special' trigger you've added to the S&H's would be activated. Might the Button [used to actually initiate the write to disk ALSO trigger the S&H refresh ?? I wonder if that would happen BEFORE things got written ?!? A little confusing

The other major thought ... Is the 'array stacking' and the subsequent 'Array Splitting' an alright technique ??? I looked at the BUS prims, and it seems there is no array access available there

Anyway, still many questions with all this. And again .... the Preset Manager ... could this not handle everything ?!?

Thanks for all the help and education

OK ... from tester's excerpt, I measure a single trigger through the schematic

I've added the Save/Load module from TROG to run actual tests.

Additionally .... in order to, both, trigger the S&H and the SAVE routine, I added a 'trigger Delay' going into the SAVE, and gave it 2 ms to first update S&H, then trigger the write to disk. This seems to work well. At this stage, I don't know if 2 ms will be enough should the data being controlled expands, or the complexity of the schematic changes.

Needless to say, the reduction to a single trigger is ideal.

The outstanding question/concern still remains, though ...

1. Is the Preset Manager only going to handle the knobs, faders,switches [as it does now], and therefore, all this User generated data must be handled separately ??? Or is there some important feature that is being overlooked??

Since I don't know, I feel compelled to ask about this.

If the PM is out, and we must use a separate routine and file ... then, is the splitting up of the Arrays [as I've done] THE [best] way to do this ? Granted, we can see that it yields the proper results ... so it is working ... but it can easily get messy to maintain and re-route this data about the schematic. I've used wireless feeds with the BUSSes to help keep some sanity in the wiring process.

Maybe I'm looking for something that is not there ... I just felt that my crude implementation was ... well, just that

Maybe I just need to hear Mr Cronkite tell me '.... and THAT's the way it is'.

and here's the lastest schematic ...

Lots of great input....thanks guys.

RJHollins wrote:and here's the lastest schematic ...

Will have a closer look soon......
In meantime, here's my version and how it runs....hope it helps somehow..

Using "array builder" to build array.
Then converting array into a string, de-limited with comma.
Saved at index value.
File loaded then line at index is extracted (thanks nubeat7)
Then usual "get at" to retrieve values.

I'm using "strings" to carry all data..so I can put... int,float text...whatever on a single line with
no issues.
There's a little circuit in there as well that checks if the user has loaded an empty preset,
and loads a default so all of the controls don't go straight to zero and drive the user nuts.
All you really have to do is decide how many presets the user can save.
This example is set to 1000, so I've a rapid search option as well.
Still looking for grey areas...bear in mind...work in progress....

Ok no i see what you mean
This will get you also automation.

So how about the Variable Server i made a few days ago:
viewtopic.php?f=3&t=1609

This may easy up the array management and you do not hav to use static indexes

For to store up more than one table i would have to make another module to it.

The variable server will then enable you also to sync parameters over tcpip (Controlling the VSTi from an external exe or other computer - Well a little useless but fun to play with )

Regards

RJHollins wrote:1. Is the Preset Manager only going to handle the knobs, faders,switches [as it does now], and therefore, all this User generated data must be handled separately ??? Or is there some important feature that is being overlooked??


If the PM is out, and we must use a separate routine and file ... then, is the splitting up of the Arrays [as I've done] THE [best] way to do this ? Granted, we can see that it yields the proper results ... so it is working ... but it can easily get messy to maintain and re-route this data about the schematic. I've used wireless feeds with the BUSSes to help keep some sanity in the wiring process.

first of all i would save everything what is needed in a preset with the presetmanager, only data which should stay the same in a project also when changing presets should be saved global,... but maybe it depends on the project u are working?
it also would makes sense to group single parameters in an presetparameter array - like effect settings ,... specially in huge schematics it could reduce a lot of primitives and modules if you have just on preset manager instead of 15 for one group - to be honest i never needed this to save loading times or whatever (my schematics are not that big)

i also try to avoid string savings - for me it makes no sense to save a,b,c when i can do 1,2 or 3 - anyway if you are using a selector you have a string and a index out...but it also depends on the project for shure there are situations you will need it..

for using multiple groups in an array i personally build up an indexing system - like each parameter has a unique id and i can call it when ever i want - so no splitting and grouping is needed just a get at prim

just a few thoughts about...

tester wrote:I guess nobody tested such things too deep.

Things I would focus on are related to trigger flow; too many unseparated flows = trouble.

Attachments

excerpt.fsm
(6.21 KiB) Downloaded 4 times

@ tester...i only just noticed this post...got distracted with your other one.....
While browsing I saw RJ asking for a way to "save all arrays inside one big array."
..so i just uploaded, and tried to explain what i was uploading.
So please don't be offended by me repeating the stuff you had already explained.

Yyyy, offended? Who? What? Why?

RJ, instead of timer/delay, I would do this. Connect "save" button only to data gathering. Gathered array = 1 dataset and 1 trigger on output. Use that trigger (second link in order), to initiate saving (prim) to file. Thus - saving will start always after you created the array. It's the order of actions, and outputs from which you get triggers.