Very nice. This is also kind of the workflow I envisioned for the system (having all the presetable parameters on the master level). You can even putt the complete Component with custom pars into the stack of the system to add all custom pars to it.
Thatâs a great feature, didnât know about that. I must say, this system is really making a difference in my little vj setup. It got to a point where I want to continue working on it instead of focusing on my master thesis 
Can you please show me your textport? I cannot read the error in your image as it seems to be inside of the component.
Also, what steps lead to that error? Did it appear on recall oder directly at start?
There is a more recent build than the one you are using in the screenshot. You can update to 2020.23680 Download | Derivative
Is it possible to have multiple time the presetFader.tox load into the same project but in different baseCOMP ?
I would like to use one preset system for every of my content base COMP. I tried to manage to reduce most of the warnings by rename the presetFader COMP once is load into TD but I still have this warning :
And is it âriskyâ to have multiple time presetFader.tox into the same project even if itâs separate into different base COMP ?
Thank you for help and dev and support
Hi Lehora,
The PresetFader has an OP-Shortcut. You can find ot on the common page of the Component under Global OP Shortcut. Just remove it and the error should be gone.
It is possible to have seperate systems running in every base, but is, at least in this version, not the intendet use, as all paths to components will be saved as absolute paths. But indeed, is still possible.
The current version im Working on tackles many of that issues by enabling relative paths and the external definition of a Tweener (the component responsible for the Interpolation of the parameters to the new values.) ro reduce performance issues.
I use the preset system in a project, where I have to use different PCs in different
locations from time to time.
Sometimes I also need to copy some components of my project to other machines.
What do I need to do in order to include the data of the preset fader in the copy to a different machine/different td project ?
Thnx for your help and greetings
knut
Hello @alphamoonbase,
thank you so much for this amazing contribution!
I think I am facing a âbindingâ related issue, probably similar to what @mase1871 was discussing before.
I would like to store values of custom parameters (no issue there) but also bind those to incoming osc messages. In this way at times I can have parameters driven by outside data, and other times, when not receiving, be able to recall the values stored in a preset I have created. Does it make sense?
For that, I was using the âbindâ CHOP â Custom parameter of a Base that is in the stack of the PresetFader. I either get errors from the preset fader, if I store presets when binding is active, or , if I save the preset in CONSTANT mode and then switch the BINDING on, every time I recall a preset the mode switches back from BINDING to CONSTANT (that is the behavior you explained in a previous post I believe).
Is there an alternative way to handle the situation I am describing? To have these two logic (incoming data and stored values) working together?
I include the patch below.
Thanks a lot!
Roberto
ExternalDataBind_PresetFader.2.toe (218.2 KB)
This issue arrives more often then I want so it seems something to take care of.
For now you can maybe take a look at my Galileo Mapper family here. The also offer an OSC Mapper which works without binding and is âTau Ceti Complientâ 
1 Like
OMG this is amazing!
They work perfectly in tandem. Thank you so so much!
Hello alphamoonbase!
Thank you so much for all the effort you put in developping such a preset system,
I am already see the use of it in my everyday life !
I was wondering if there was a way to call different cuelist, to store them, and call them back later when you want to change it for exempleâŚ
Moreover if it is possible to let them play in background ?
For exemple, recording positions of â group of fixture, play them, and open another cuelist to play on some other parameters or group at the same time.
Thanks a lot !
Bestsss
Hoi. So the way the system works is that you have the presetManager in the center. You can use the manager to store presets completly agnostic as storing a preset is based on the current stack (like the programmer on an MA or manual values oon an ETC desk). You can the use the CueList component and point it to the presetManager and use all the presets available on that instance of the presetManager.
For the dashboard (and I think also cuelist?) You can A: define a tag to be able to give several presets the same name, and define a preset which stack should be used if you record a new preset from that component.
Another way is using more then one preset manager and dropping a seperate tweener into the project to save on ressources. Its all very flexible
Regarding recalling presets while another is running: only thing to consider is that a new transition will overwrite the current one.
1 Like
Hello,
I have a question regarding the use of the presetFader and the cuelist.
When I create a new preset with the presetFader, it correctly shows in the selectable presets in the cuelist. Problem is when I add to a prexisiting preset one parameter (this happens very often to me when expanding a network with new eposed parameters⌠guess it should be normal) and I store it again. If I recall the preset from the presetFader everything works and the stack gets correty updated with the parameter that I added. On the cueList though when recalling that preset, the stack doen not get updated with the new parametr. I have the impression that updating in one place does not reflect on the otherâŚsurely I am missig something 
Thanks a lot for your contribution and your help. I am basing all my new works on your preset system, I am very grateful.
Roberto
Hmmm, its been a while to be honest scince I worked on it
This might be a simple issue of the cueList not forcing a reload of the Stack. (which is good as reloading the stack can tank quite some ressources because of some bad programming from my side ;D )
I just released a rewrite that declutters everything and brings more stability.
1 Like
Thanks a lot! I was still using the 2.195.
Do I understand correctly that now the stack does not change among presets? That would make sense to me. So if I decide to add a new custom parameter in the stack I can just drag & drop again the container on the presetManager and also the previous presets (the ones I created without that parameter) will now show the parameter in the stack?
Follow up question, in the documentation you mention:
" * Give your component a tag containing the keywoard preset. Now, when you change a parameter, it will be added to the stack automaticly."
Does the keyword (does it mean the name of the container operator?) need to be âpresetâ or âpresetxxxâ?
How would be best to âdonateâ for this project?
Thank you again for your help.
Hoi Roberto.
The initial concept of the system was to have one global manager taking care of all parameters and presets. For this I enabled the âHot-Reloadâ of the stackk. This way, you could recall a color-preset, change the color, and store a new one without the need to look at the manager at all times.
Regarding the auto-fill: This feature got removed in version 3. It was a somewhat neat idea and was one of the first. This way you could adjust parameters and store them instantly. For this reason there was also a Clear Stack on Record parameter. But this also got removed as I think noone really used this feature as it was somewhat contrived and born when I was targeting lighting-desk-behaviuor.
The idea nowerdays is to have one preset-manager per component/area and only setting the stack up once.
The parameter-interpolation is completly externalized, so no performance-penalty here.
Regarding Support: I have a Patreon, mainly targeted torwards support of the OLIB, but also always nice to have a supporter there. Iâm also offering coachings on my highest tier.)
1 Like
I updatet the tweener and preset-manager component to work with bound parameters.
For existing projects replace the PresetManager component and delete the Tweener-Component in / and all should be going good.
Just discovered this - amazing work! One note - I seem to be having a little graphical error; some of the buttons are missing from the Manager and Cuelist UI. I was really confused while trying to figure out the Cuelist as it looked different from the example in your video, until I discovered the buttons are actually present and clickable, just not visible. It took me a second to realize the âRemoveâ button was also missing from the Manager UI.
Here is what Iâm seeing:
Is it possibly a TD version issue? Iâm on 2022.29850 (on an M1 Mac).
Hoi,
interresting. I suppose you are missing the font for the simbols (maybe?) It is still using the old SegoeUI elements. It might be that they only come with Windows.
I will see if I can update them in the future to MDI.