@alphamoonbase
here is an example inside my works PLAYER_LED.toe (1.5 MB)
about your questions:
- no errors opening on others computers. just the problem described if the stack is full or not.
- the .toe are identical on all coomputers (same parameters and same use)
- i will add the executeDATs as you said. seems to really help.
- do you think that is better that i use my project in 2019.19930? i can do that if it improves.
- i will also try into my project the new presetFader.tox you sent.
- i save all my presets in the cuelist! from the presetFader i only need to hold the parameters.
note: for each performance I will save different presets. i will never use the same saved.
thank you very very much for the feedback!!
Edit:
you need to add a folder āvideosā in the same path as your .toe project to get it working with contents
@novasfronteiras : Thanks for the file. Seems like this feature (load of stack on opening the file) is not even implemented the current version (2_55). In this case you probably recalled a preset pretty fast after startup and filled your stack this way (it will always be clear on startup).
So yeah, the setup I posted will help. I will release an updated official release soon doing it alone. For this time use this one (the one i posted above is not working. Hotfix releasesā¦):
presetFader.tox (251.5 KB)
Thanks for the feedback and have fun!
Edit: Just had a look into your file. Seems like the Export method is busted. Really curios. I will dig deeper into that!
1 Like
tested here and seems perfect!!! 
anything new or later impressions i tell you here!
thank you a lot!!
2_174
.You can now also store expressions. The engine will fade in and out of expressions.
.You can edit the curves andadd your own ones.
.The Dashboard and Midimapper now can get Tags to help organize your presets.
.Organized the UI elements a little bit.
.Updating the Color of the Dashboard now works.
.You can now store and load banks inside of the same Dashboard.
.Randomizer got a nice button.
.Dashboard got a button to map existing presets to a button.
.You can now load all presets or filter presets via pattern matching to populate it.
.Internal enhancements.
Hey @alphamoonbase!
Iāve tried using your plugin and itās really great, however Iāve got a few questions:
- In one of your videos you seem to simply drag OP onto presetFader and it stacks all of itās parameters into the list. How exactly does one do that? Attaching a gif of how it works on my screen:
http://g.recordit.co/MnPcntneMW.gif
- After I set my presets on the fader I would like to see them on presetDashboard too, however when I press Load Presets it simply outputs me 1 big empty button. Iāve tried recording it manually on the dasboard too with no luck either. Attaching another gif:
http://g.recordit.co/yTG3AQpOAy.gif
- I understand that with midiMapper we should also be able to map these preset faders onto midi knobs and transition through it when turning it (right?). For some reason, midiMapper just stays blank for me no matter what I do. Am I missing something?
I can see that you put a lot of effort into this engine so I believe thereās something I donāt get. Regardless, it looks really promising and I canāt wait to utilise it 
P.S. Iām using 2020.20625 build.
Wow, thanks for a quick response!
- That makes sense, thanks for clearing that out.
- It did help when I deleted initial page.
- Fair enough. For some reason I had an impression that itās something similar to Zerror plugin posted on this forum earlier where you can fade between different OP states.
Either way, itās a great!
I definitely agree on the freedom of UI, I believe for anyone who actually uses these presets having a custom UI is important. I can also see how your approach is a lot more versatile and scalable which is always nice with TD plugins.
Iāll try to keep an eye on this goodie as I can see itās getting pretty useful. Keep up the good work!
Culmination of some of the work done in the streams and lots of bugfixes. Find bugs, let me fix them 
2_195
.Made in and exporting presets more robust.
.Implemented a CleanPresets() method to cleanup existing presets of no longer existing refferences.
.Stored expression now actually will be set at the end of the recall.
.The Dashboard can now name presets directly on record.
.Added the CueBuilder. This component can be used to put several presets together, but with distinct timings and curves. The CueBuilder can just be refferenced by the companions and features most of the same API as the others. So you can put that collection of presets in, for example, a cuelist.
.Internal Bug Fixes.
Hi again @alphamoonbase,
silly question - how would you trigger a preset with a momentary button click elsewhere in TD network (I assume thereās a simple python expression)? Thanks!
Hi. Yes, thats no problem. There is a big set of function calls you can do on your own.
What you want is the RecallPresetfunction.
RecallPreset(self, name:str, time:float = 0, loadStackOnRecall:float = None, curve:str = 's', tag = ''):
In the newer version of the file, the engine has a global op shortcut āTAU_CETI_PRESETā. So you can just call it from everywhere.
op.TAU_CETI_PRESET.RecallPreset(āMyPresetā) #Recalls the preset MyPreset in 0 seconds
op.TAU_CETI_PRESET.RecallPreset("MyPreset, time = 4, curve = ālinā) #Recalls the the preset in 4 seconds with a linear interpolation.
2 Likes
Damn, that is insane! Your contribution to this community is much appreciated @alphamoonbase 
1 Like
So, not sure whether thatās a bug or simply the nature of the plugin but I thought Iād share it regardless.
Hereās a quick demo video and also a short explanation below:
https://recordit.co/ieElBdAEBj
Letās say I have a particle engine which has itās āexternal force xā value binded to a knob. When I move the knob, the value of external force x changes and vice versa. Now, when I recall a preset and reset external force x value to 0 (the button is off-screen so you canāt see it, but pay attention to how external force x value starts to decrease gradually), the bind ābreaksā so to speak and I really donāt know how to solve this.
Iāve tried storing itās value before and after creating a bind, doesnāt work either way (actually if I try to recall a value that has bind to something else, preset engine gives me an error and doesnāt recall anything at all).
All Iām trying to do is have a way to control a value with a knob but also be able to restore it to itās default with a simple button click. Hope I made it clear.
Good catch. Will def. take a look at it as even the bound slave has another mode then the CONSTANT mode (or at least setting the constant mode overrides the bind slave state.)
Edit: It is not the setting of the constant mode. Can you please say which version of touch you are using?
Edi2: Another one. Which parameter did you put in the stack of the engine? The slave master (the one of the widget) orthe slave?
Edit3: Please attach a demofile and which version you use. With 22080 Iām not able to reproduce that error 
Iāve made a quick demo file, have a look. Iām using 22080 version.
In the file, Iāve created particlesGpu engine and binded knob value to itās āExternalxā value under Forces tab. Also, in another base called āglobalā Iāve imported tau ceti engine and created a preset called āparticles_defaultā. Once I recall this preset, the bind between knob and particlesGpu engine breaks.
Let me know if you can reproduce the effect.
demo.toe (1.6 MB)
Thanks for the file. I was able to reproduce the error.
Even though i could not reproduce it at first, the error stems from the mode of parameter you have in the stack being bing (purple). When binding the parameter to the widget parameter (and not the other way as you did) it has no problems at all.
Will dig into the issue tomorrow and see why I could not reproduce the issue at first.
This way it works:
1 Like
Gotcha. I always thought it doesnāt matter which way you bind it as itās supposed to work both ways. And once again, thanks for a thorough explanation!
In theorie yes, but for the preset system it is not that easy sadly, as I also support the implementation of expressions. As Binding sets the mode of one parameter to something differrent then CONSTANT or EXPRESSION, but actually BINDING it is kinda difficult to implement, as BINDING does not have anything value related stored. So storing the binding expression in the preset would also bring some unwated behavior. I will see if I can implement binding mode in a good way, but for now the mode of the target parameter should be CONSTANT (grey) or EXPRESSION (blue). Exports are dead anyway (fight me ;D ).
Gonna handle bind mode the same as CONSTANT in the future.
I thought so that bindings can cause some troubles when reverting to stored values. And I totally agree with you on exports - theyāre very inconsistent and I wonder how much more efficient they are compared to expressions.
Also, just to add to your previous point about the hierarchy of binding the parameters together, I found out that storing top-level parameter values and then binding that all the way down to the final operator seems to work better because then Iām able to adjust knob min/max range through customise component. Otherwise, if the actual operator value is stored and itās binded all the way up to component parameters, Iām stuck with knob values being from 0.0 to 1.0 as it canāt be binded both to operator values and itās container parameters (if that makes sense).
Edit: Adding a very primitive explanation in case anyone else faces a similar problem in the future.