-
-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Automation Parameters to Realearn #11
Comments
I'm planning to add a similar feature which should cover all your use cases, if I understood correctly. I call it "Conditional activation". The idea is roughly as follows:
Additionally, I think about making the generic parameters available in EEL transformation formulas. That allows one to parameterize a mapping. I also thought about adding one VST parameter for each mapping: "Enable/disable mapping 1", "Enable/disable mapping2", etc. But I think the above mentioned feature is more powerful as it allows you to quickly enable/disable complete groups of mappings. And it doesn't have the problem that everything breaks apart as soon you move/remove/insert a mapping. Feedback about this idea appreciated. |
wow, that's much more than I was expecting, thanks @helgoboss! This sounds much more exciting than what I was thinking of! I love the idea of Conditional Activation. I think Generic parameters could solve a lot of potential use cases in transformation formulas. This would allow, for example to use a single non-momentary non-toggle button/note to control 2 different parameters (effectively a second-press functionality, which, correct me if I am wrong, is not available in realearn currently). If I can add a little suggestion, I'd like Control and Feedback activation to be separate. In my setup I have a 2-level control, where the first level are all buttons, which determine which plugin the second layer (knobs, exp pedals and leap motion) controls. Originally I had a separate realearn for each plugin (plus the master one for buttons), which is an overkill in my opinion, now I settled having just one, and wrote a custom EEL script to filter the feedback just to the selected plugin. I am interested to understand a bit better how, from a UI/UX perspective, in your framework, you link Generic Parameters and the dropdown menu you are describing. Are you gonna have a dropdown menu like the ones you would have for midi input? So that for each mapping you can decide exactly the Generic Parameter it is linked to? Sounds really promising though. I wish I was a better programmer and could provide more hands-on help. |
It makes more sense to have this in MainProcessor because this should contain the majority of processing logic and be able to work on data structures that are suitable for processing. It became obvious when realizing that - in order to implement EEL activation conditions - in the build stage (Session) we need a string but no EEL processor, in the processing stage (MainProcessor) we need an EEL processor but no string.
there's always EEL for more advanced scenarios
@jackmau You can try the feature in https://github.com/helgoboss/realearn/releases/tag/v1.11.0-pre1. It implements everything mentioned above with the exception of using parameter values in control or feedback transformation formulas. I will probably implement that, too. But it's a feature on its own an deserves a separate ticket. |
Hi @helgoboss,
thank you for your amazing products! I am a huge fun of both Realearn and and an avid playtime user. I am really glad you have restarted working on realearn, it is an amazing product. I have a lot of request which would make my setup much simpler to use and less reliable on a series of work-arounds I've built in a long JSFX I use in conjuction with realearn.
The first request is about finer way to control realearn from another realearn instance, without having to create a zillion of instances and/ or arm/select tracks. I am thinking to a parameter list similar to the one currently in playtime. Ideally what I would need to access are:
I don't mind having actions instead of automation parameters if they are handier to implement.
Accessing internal mapping parameters would be interesting, but probably not worth the effort, I'd rather duplicate mappings if I am able to programmatically active/deactive them.
This would allow me, for example, to have a single button toggle between two relative states (hitting a realearn session that activates/deactivates a mapping in another realearn session). It would also handy to manage feedback in situation you have multiple mappings for the same controller.
The text was updated successfully, but these errors were encountered: