so im going to describe this midi issue, something Id like to do , but im not really sure how you would like midihub to attempt to solve it … so what modifiers might be need or not .
the ‘issue’:
I have a synth engine that does not support a sustain pedal (CC64),
what Id like to do to put the sustain handling in the midihub basically by ‘withholding’ midi off messages.
so basically
CC64 > 0 : start caching note numbers for note_off (you can delete duplicates)
CC == 0 : send note offs for all held off. (I don’t think anyone cares about release velocities)
note: when a sustain pedal is lifted if only clears those notes that are not actively held, hence why we ‘cache’ note_off numbers.
so I can imagine this as a ‘simple modifier’ dedicated to the purpose,
OR perhaps this is an example where a scriptable/user created ‘modifier’ is preferable,
since its quite a specific user request, not sure how many would find it useful
so perhaps this is the sort of things users might build for themselves?
Id even be quite happy to write this in C against an api, and compile on ARM… perhaps this could lead to users sharing modules
C is not very friendly, but Im thinking its probably the easy solution initially, as just needs compile/linking into binary going to midihub. and Id be happy to have that as a separate development environment from the midihub app (so you dont have to start shipping compilers )
so, perhaps a first step, later a more friendly scripting language perhaps could be created, if the desire.
Hey! It’d be a good idea to add custom pipes functionality to Midihub, but the device does have a limited amount of RAM available and at the moment it’s built around static memory allocation for specific functions (USB and MIDI buffers, merge buffers, pipe data itself, upcoming MIDI mappings), so we are in control of the memory tradeoffs between different subsystems to be able to implement a device that provides advertised functions in a reliable manner. Custom pipes would definitely require a more dynamic memory system to allow custom state tracking such as the notes held down at a given pipe, so it’d be a pretty big change to the current architecture.
However, I don’t rule out scriptability in the future versions of Midihub software.
At the moment we’ll look at how far we can get with taking in the suggestions and producing the pipes for them in a way that fits the current architecture or the changes are manageable. This suggestion in particular would require more storage per pipe to be able to keep track of the entire note spectrum. At the moment each pipe has a fixed amount of RAM storage, to be used for both the arguments and space for internal operation. We could allow chained ‘hidden’ pipes to be used for additional memory storage for one main pipe such as the one you describe. This would be useful in some more situations, so I’ll note it down in the roadmap and at some point we’ll get to implementing it.
yeah, i know its a tricky one - limited resources, and also opening up an api also its quite difficult to support.
it could be done in 7bits , since its merely a flag for each note (0-127), but yeah i recognise the more general issue.
specifically this is not an issue, i can use an axoloti to ‘front’ the synth and do this, it was more an example to show the kind of things user might want be able to do/overcome.
sorry, of course your right - should never reply before my morning coffee
in my situation its actually a mono synth, so 1 note…
but i can see a limit like 8 being reasonable, it won’t solve it for all, but will cover a good set.
background: im actually using the sustain pedal to hold notes, to free up my hands so i can tweak a modular with both hands.
Could you just strip the note offs and then send CC123 (Panic) as a way to stop all notes. Then no caching needed.
Or will this have the wrong effect you’re after?
There could be some unintended side effects when sending all notes off, especially when merging independent MIDI streams. Anyway, we already did implement a full sustain pipe without note number limitation.
)
This suggestion in particular would require more storage per pipe to be able to keep track of the entire note spectrum. At the moment each pipe has a fixed amount of RAM storage, to be used for both the arguments and space for internal operation. We could allow chained ‘hidden’ pipes to be used for additional memory storage for one main pipe such as the one you describe. This would be useful in some more situations, so I’ll note it down in the roadmap and at some point we’ll get to implementing it. 
In that same amount you could fit 17 7-bit values.
