So when mapping a cc in zynthian… it would be nice if one could assign a min and max to the mapping… the reason is because when some knobs are turned down they’re on minus ranges, it would be super useful if that could be used to bias those controls to be positive
1 Like
I feel like ranges should be in two places, it should also be in midi filters.
I’ve been dealing with a lot of mapping issues that I feel we should be able to find solutions for…
I think it makes sense for the midi filter scripts to have some kind of evaluation so one can punch in special behaviours…
Here’s my examples
Calf filter has the wrong knob curve, putting all the action right at the start… Easily fixed with simple math
The whammy effect for transpose should be able to switch off when it’s close to The original pitch, easily done with filter eval to generate cc values 0 out of and 128 in that range
Some ranges extend into the negative, like the dub delays, they can be ranged 0 to 110 easily making the knob twice as expressive and useful
The range of the delays are too wide putting all the action right at the start, another candidate for solving with ranging or eval scaling
I know if some very efficient js execution setups that can run on potatoes, we could use that or python if we have to, i think it’s worth it
If we want something more user friendly there are open source spreadsheet calculations libraries, they support very flexible formulas which would also work
My favourite candidate is js because it survives copying and pasting the best, making it easy for people to distribute and combine ideas
This may be related to this feature request. I doubt we will be considering including another programming language like js any time soon. (Four languages feels more than enough!)
Instead of counting how many you use, count how many the user has to use, the end user should not necessarily be expected to learn or enter python, that’s the developers language
The language for filters is already an additional language, it might as well be any other.
Always use the best tool for the job, never use arbitrary rules to make your choices, 4 is not a relevant number here.
I implement systems that run on many languages all the time, the only important factor should be how well does it perform, how hard is it to implement and how does it feel to use…
A little digging revealed that pd has something called expr which might be easy to learn, copy paste friendly and already available and realtime oriented, is puredata low overhead?
I believe the end user shouldn’t have to program anything at all, but just playing music. Naturally if PureData is his favorite tool, I guess he know how to deal with its programing language.
Puredata is honestly a nightmare, if there was a simple js layer for evaluating midi modifications it would be a thousand times easier than puredata (it really would be a good candidate for the midi filter language, allowing it to be flexible without writing a lot of custom code), I just tried to set up a midi filter that does a few things in PD and it’s honestly a lot harder than programming…
something like quickjs could really do a good job for this
Maybe you can propose some quickjs demo code for evaluation in the Zynthian environment ?
That sounds like some interest! I’m really just beginning to find my bearings with zynthian but I’ll be willing to give it a bash
one thing that might be useful with this kind of setup is that I set up a testing environment that just runs in the browser (browsers have midi and js) and shows you what you can expect it to output, where the filters you set up will just work when copied over to the zynthian
If we set it up as text in/text out then its just piped text we’re processing, if we’re unhappy with quickjs later we can easily swap it out for anything that can process text
You’re all sorts of wrong here, pushing the onus onto zynthian. The correct answer is for you to fix the curve in the source code for the Calf plugin. Or add an option to it so make the curve selectable.
The problem we’re solving here is not plugin problems though, it’s zynthians inability to easily remap its midi behaviors… solving it by updating all the available lv2’s of which there are many, is the scenic route I agree, but we can also solve zynthians ability to map midi easily.
Anyway, what you want to achieve looks like it can be done with this plugin
You should look at the mapcc filter
So here is my proposal for how it works, tool receives incoming text, dumps outgoing text, which creates an easy processing pipeline that can be changed down the line, reduces the codebase and feature maintenance of zynthian and allows easy mapping.
Here is the staging tool for processing scripts https://midi-filter.glitch.me/
You’re also completly ignoring the fact the core dev team will have to support that. Why should they have to learn javascript when you inevitably dump the project and run? What a monumental waste of energy that will be.
The dev team already has javascript code in the webgui
Also, they wouldn’t have to learn any javascript, its just the filter code, the end user is the only person that uses it, and it’s just expressions, I think you’re squarely over reacting.
I’ve just finished the midi filter code, its a lot shorter than the original hard to maintain parser.
Orrrr, they could use the plugin which doesn’t need any coding experience.
what plugin would that be?
expressions dont require coding experience
The plugin? It’s a secret. Carefully hidden. As someone who teaches coding. Expressions absolutly have to be taught. Consider ( varx < 10 and > 20) it looks like it should work, but unless you have varx on both sides of the and it wont.
1 Like
I almost agree with @Baggypants here. Most of cases expose by @lanmower should be solved in the plugin side. Indeed, some of them could be fixed with some TTL customization without modifying the plugin source code. This is the right way. Fix once and for everybody.
Of course, having range and offset adjustments is still useful and can help when the parameters is not well integrated due to poor TTL or coding. I would like to add some options for these into the controller options submenu. Something like:
- Linear/logarithmic flag
- Range / scaling adjustments
@lanmower, have you tried to fix the TTL for some of the parameters you describe? You will find a bunch of examples in this fólder:
/zynthian/zynthian-data/lv2-custom
Regards … and merry xmas!! 
1 Like
Such an addition should also include offset.
Merry Christmas!
2 Likes
Well, if you specify the range (minimum & maximum values), offset is implicit, right?