Open up the Midihub editor for public contributions

Midihub Feature Requests
1

Would it be possible to give us a scripting component inside the Editor (and of course the firmware) which we can program ourselves?

I find the Editor quite limiting and a bit annoying to use and I would love to stop using PureData as I don’t want to rely on a computer while playing.

Cheers :clinking_beer_mugs:

2

Hi, at this time we are not considering to open the source to the Editor or the Firmware. However, the development is ongoing. Could you provide more details what in particular you find limiting or what other improvements you’d like to be made?

3

Hi there Giedrius,

I wasn’t thinking to open source the projects, but instead that a new pipeline component could be added which would allow the user to write scripts which are able to process midi messages as inputs from the pipeline component that comes before it.

What would I use a scripting block / pipeline component for?

One example I could share is the scripting of procedural music tools which leverage deterministic and stochastic processes (Mandelbrot set, Markov chain). Being able to use the self similarity of deterministic processes to provide structural information which could be used from the compositional structur level down to the velocity information of each note. Midihub would then become a serious option when writing Process based music.

Second to this, I imagine you have lots of user personas that have different needs. I for one am comfortable in a development environment where I can work quickly code and I find learning new things hard due to my own personal traits. I experience the Midihub Editor as tediously, but another users love it - and rightly so, clearly a lot of thought has gone into balancing creativity and reliability. Giving more flexibility to the code happy users like myself might make users like myself love the experience even more.

Final thoughts;

  • A feature like this would come with nonfunctional requirements which would need investigation. One that comes to my mind now is, How would the device handle Processing Power limitations that may arise if the code being ran introduces unacceptable amounts of latency due to it being either too demanding to run or the code is just poorly optimised. Maybe for a feature like this you would need to have the user accept a disclaimer that it’s possible to introduce undesirable side effects and that no support will be available to trouble shoot them.

Other ideas;

  • You could let people share their scripts on patch storage and these could be mined as candidates doe new pipeline components in the future.
1 Like
4

Resonotter said something in an earlier post mentioning:

“Makes me hanker for arithmetic pipes again :smiley:”

what was that about?

5

Oh yeah, that was us last year returning to a 2020 discussion about Pitch bend to note

What I meant would be covered by @davidpower’s idea of a Script pipe, but I think that approach would be a bit of a “sledgehammer-nut” for what I was hinting at:

TLDR

“arithmetic pipes”

is the term I use for a very small collection of pipes that would do rudimentary arithmetic with defined inputs:

  • Midihub is, IMO, very neatly designed to do a bunch of “musical” things very well.
    As a result if offers functionality like Rescale off the bat…

  • but, when you start to want to do something like general† addition, then you need to consider work-arounds like “convert → note, transpose by mapped amount, convert → CC”
    ( † specific addition shifts might just use Rescale)

  • These “easy” workarounds become quite standard, but getting Midihub to do, say, modulos is really quite tricky.
    (as is doing a ratio-sum, ie µA+(“1”-µ)B, of two inputs)

So each time one of these operations is needed, being able to reach into the Midihub toolbox for that simple pipe would save between 3 and 30+ pipes (and a lot of head-scratching!)


What unites my (tentative) request with the OP’s is that balance between extra functionality and accessibility:

at what point does adding (more “abstract”) functionality…
…that might be a game changer for some users…

…just end up making the Editor less accessible for many others!?

As such, I would almost want such improvements separated in the Pipes panel so that new users know to leave them alone until they’re more familiar!

“Script” Pipe considerations

I think @jboyd’s idea adds to previous discussions in that it hints at two notions that are crucial for the majority of users who would like the extra functionality “off the peg”:

  1. a bank of well written pipe “presets” :asterisk: which would do new weird and wonderful things easily

  2. confidence (or at least knowledge) about latency effects

I would love to see this but I think it’s no mean feat:

I sense that it would take a lot of clever thinking from @Blokas to make the interface really accessible to a variety of coding inputs and a community of willing helpers to make each scripted preset optimised and well documented

:asterisk: I’m picturing a single Script pipe which, like Micro Scale, has a drop-down for a small collection of user-loaded scripts. The number available might depend on the aggregate byte-space used

1 Like