Connecting monome grid to hermod and have new fx as ansible apps

I really love hermod, i found myself multiple times thinking about possible new fx types, and thinking about how great it’d be to allow people to develop FX for hermod. To open a bit the machine

For example how great it would be to connect a monome grid to hermod, and to have available as midi FX the different ansible sequencers ? ansible | monome/docs

What do you think???

Open sourcing hermod would be a lot of fun, but I’m not sure how well it would go with actual firmware. You probably might have to give up some of the present function to add some other, i think hermod is pretty close to hardware and software limits

Ansible and monome : no, not interested, standard midi support is enough. If you want to use monome with its sequencers, use monome and its sequencers. I don’t think adding hardware specific fx would be good for the hermod. I couldn’t care less for monome stuff, never been interested, but i do use the djtt midi fighter twister. Would you be interested in adding fx to finally be able to use the switch encoders on the midi fighter twister?

I guess it’d for sure need a different firmware but I’d love the idea of having fx community developed plugins.

Ansible and monome : no, not interested, standard midi support is enough. If you want to use monome with its sequencers, use monome and its sequencers. I don’t think adding hardware specific fx would be good for the hermod. I couldn’t care less for monome stuff, never been interested, but i do use the djtt midi fighter twister. Would you be interested in adding fx to finally be able to use the switch encoders on the midi fighter twister?

The whole thing of making it “open” would be to cover this kind of needs. You wouldn’t “install” a monome-driven plugin , but you may be would install a fighter twister driven plugin.

Missing morecreative sequence generation*
For sure Hermod is awesome for recording a midi sequence and manipulate it a lot with its fx ( I love chance, random octave, glide etc… ) , but one of the things I miss is more creative sequencer to put on at the start of the fx chain ( things in the line of Fuge Machine , monome/grid/norns style sequencers… ).

I’m also very interested in @thetechnobear opinion given that he did lots of interesting work “opening” the Organelle ( I now it was already open because of pure data and so on… but with Orac he brought it to a whole new level )

Regards!

open sourcing is a very much the developers decision… (so Squarp in this case)

developers spend man months/years creating their software, so rightly feel they need to protect this investment from other (hardware) manufactures just cloning thier hardware, and using that software.

others, feel thats its opportunity for the community to help grow the platform, resolve issues etc.
so open source is tempting.

Emilie from MI, whilst she open sources the firmware, its after a time which she feels has recuperated enough of her investment - however, this partly works because of how successful MI modules (esp, in recent years)

this touches on another factor…
really open sourcing only benefits users and manufactures IF open source developers pick it up and run with it.

there are only so many open source developers (with appropriate skills) for doing this kind of development, and honestly, we have to pick n’ choose which projects we spend our (free!) time on.
so for someone like Squarp, they have to ask themselves is anyone likely to want to participate in development - if not, then its just a distraction.

(e.g. Mutable modules are very popular, so that means they are more likely to attract developers, but even then, theres only a few couple of forks even for thier most succesful modules ! )

so, its a hard decision to make - and certainly not something we should expect of developers, rather be very grateful when they are generous enough to make something open source.


as for practicality with something like Hermod (or Pyramid)…

these run an MCU which dont run an OS (in the sense most users think of it) , which means that they cannot dynamically load code in the same way as something like a rPI/Organelle/Norns can.

rather, like MI modules, a developer would have to fork the entire firmware to supply a new function (e.g. midifx) - this makes combining something like midifx from multiple developers an absolute versioning nightmare.
it also means, if Squarp release a firmware update, any ‘forks’ by 3rd parties, need to at be adapted and rebuilt.

also, frankly, end-users are much less likely to use 3rd party firmware … thats just how it is, they feel more confident with factory firmwares and also ‘add-ons’

as for 3rd party developer, its also much harder…
the codebase was not designed to be ‘understood’ outside of the original development team, it also likely has little ‘development documentation’
it would be enourmous effort to do this (Mutable Instruments do NOT do this at all), which means the effort is placed on the 3rd party developer to ‘grok’ all the code, and build an understanding.

this goes beyond just ‘adding a midi fx’, a new fx, might need to inspect the timeline, it might need also having timing constraints…

finally, whilst i might have ‘great’ ideas for a midi fx, it may just not be possible/feasible given how the firmware is written. which I wouldn’t know until I know the firmware source code intimately! ( * )

I’ve written and extended both firmware (like this) and ‘add ons’ (like orgnanelle/norns etc),
sure it can be done, but its quite different…

Im a huge advocate for open source development (I actively develop for quite a few open source projects), but its not a panacea for every product/project.


( * ) this is why I always suggest people ask @squarpadmin about possibitlies - we as users, have literally no idea if our great idea is feasible/practical since we have no idea how the firmware is written - without that its pure speculation… even if you know 20 other sequencers that can do it :wink:

ooh, one other point to mention…

something like developing support for the monome grid for hermod tends to be ‘less likely’.

the issue is simply, you now, not only need to find a developer that is interested in developing for the hermod - but they also have to be interested in the monome grid - so… its a niche, within a niche.

ok, in fairness, this is not pure coincidence… (which would be highly unlikely !)
it could be if the hermod was made open source, then this attracted a monome developer to buy a hermod because integration might be possible.
but honestly, most often this occurs because the original developers already have this interest/connection - so do it for themselves. ( * )


( * ) Id say monome products are not sold in enough volume, and a bit too pricey, to generally be worth considering supporting in a ‘product sense’ .


actually to end a bit more ‘positively’ ( as these posts are really the ‘practical’ viewpoint :wink: )

we are starting to get alot of ‘programmable’ modules in eurorack.
things like Bela Salt, Terminal Tedium, Electrosmith Daisy (including noise engineering variants, O&C , Befaco Lychi, Percussa SSP.

its generally much easier to program what you want on these modules, as they are developed for it.

so really there are plenty of ways to add custom functionality to eurorack modules these days.

fair enough :grinning:
thanks, i got your point and appreciate it the explanation!

Let me add one question, may be is not about doing the whole platform open source, but the possibility to have some kind of open doors / callbacks / etc… and the capabilities of bringing open source programs ( or custom made programs ) into a notopensource/mcu/firmware environment?

So, I don’t know, may be you can have a folder on startup in which firmware goes and looks for it, and developers can add a code file that uses apis from the firmware ( In the case of midi fx takes the input from the left with api’s , modifies it with code and thows it to the out api’s the result so the next midi fx can use it… ). Like community driven scripting files…

Thanks anyway!

thats what I meant by saying dynamic loading of code is nowhere near as easy on an MCU , as an OS (like windows, linux, macos) , there can even be some hardware restrictions like only running code from flash. so no, generally this is not viable for mcus.

as i said, if you want that kind of functionality, you’d want to look at something like bela / rpi/terminal tedium which are linux based, or something like O&C/Teensy/daisy where basically they allow easy user flashing.

for something like Hermod, then really the only thing they could ‘easily’ do would be to release the entire firmware, and then developers could fork it.
but… as discussed, thats a whole can of worms, and something many manufactures dont want to to do.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.