Preset System - 2019-10-23 13:58

@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!!! :upside_down_face:
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:

  1. 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
  2. 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
  3. 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 :slight_smile:

P.S. I’m using 2020.20625 build.

Hi @mase1871

  1. Simple :slight_smile: This only works with custom parameters for components. You can create a customparameter by right clicking a COMP Operator like Container or Base and selecting ā€œCustomize Componentā€. Then youcan just drop the parameter of any operator inside that component into the customization screen.

  2. This is indeed weird behavior. Youcan use the Map mode (second row, third entry) to map any existing parameter to a button. Maybe this might help. Also for the start it might be a doog idea to disable the autoload . I will check out why it is not working correctly.
    Might habe found the Issue:
    On page one, there is one parameter with the value of ā€œColorā€. Clear this parameter to be empty and then you should be able to load all the presets. Forgot to clear it before release. My bad.

  3. The MidiMapper is a pretty Lightweight component only for Recalling and Recording presets via Midi Notes. All the feedback is given via the midiDevice. I might find the time to make it more user friendly but i just built it for a show and as a concept.
    When you set the mode to Record and press a key or pad on your midi device you will see that it creates a new preset with a silly name like ch2n34 which is the corrosponding mapping of your midi note just played. Manually scrolling trough the presets is sadly not possible as the whole system is based on move instructions.

Wow, thanks for a quick response!

  1. That makes sense, thanks for clearing that out.
  2. It did help when I deleted initial page.
  3. 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!

  1. Nah, its kinda different. Not in a Linear way. Im actually thinking about a way to implement this with relative presets but doing a user controllable fade from a to b would mean taking control out of the user hand. With the Zerror tool you have to define your UI via the same tool first making everything easier as you have more control over the values.
    My system is more open in a way as it is not bound to any UI solution but just the concept of parameters which can be changed from basicly anywhere.

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 :slight_smile:
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 :slight_smile:

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 :frowning:

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.