would be useful to eventually be able to be menu-dive free during a live performance by loading+autoplaying via midi controller
the simplest idea i could devise, versus a whole new squirrely ui section for assigning/organizing midi per patch, just have users name their patches with a specific convention.
for example:
HelloWorldPatch-[pcm123ch1].yml - thus would be loaded+autoplayed via program change message 123 on channel 1
blahblah-[cc15ch5].yml = loaded+autoplayed via cc#15(>64val threshold cross) channel 5
BestPatchInTheWorld-[nt9ch7].yml = loaded/autoplayed via note#9 on chnl 7
mm would just parse whateverâs inside those brackets. and if easier for mm, have the users dump all their specifically midiload-named ones in a folder called âmidiloadâ (versus mm having to scan the entire card on boot?)
hope that idea makes sense!
also for the autoload thing, perhaps a global menu setting: autoplay=on/off?
Ok, yeah something like this is possible. Maybe start it more simple at first like autoload/PC099-patchname.yml and limit it to PC events. At least that would let us get auto-loading running, and later we can add a more streamlined UI and attach to other events besides MIDI.
There is one technical thing, though. When changing patches the outputs fade down and then the new outputs fade up. So if itâs outputting audio, there will be a brief gap (which depends on how long it takes the modules in the patch to initialize themselves).
oh cool, really glad its actually a doable thing and that makes sense on a gap between patches. having a vol ramp down/up between loading definitely seems way better than a rough digital pop
HI there! Would it be possible to use PG events along MSB-LSB values? MSB values would correspond to folders listed alphabetically that can contain up to 128 patches.
Came here to make the same request. Happy to see itâs already made, and that it appears feasible.
@danngreen ⌠I wonder if could have any update if auto-loading patches via MIDI PCs might make its way into a dev update?
As @offthesky mentions, this would be a highly âlive performance enablingâ feature. I play guitar alongside my modular, and use a MIDI footswitch to send PCs to change presets on several effects pedals simultaneously. Would be great if the MM could be integrated in that.
This feature would be really great and would really open it up for live performances. I would hook up a Launchpad and use Custom Mode to assign program change messages to pads.
This feature would be really helpful for live performances and as i am building a live setup that is centered around the meta module, changing MM presets via MIDI PC would be sick!
Just a thought: Maybe the workflow could be a table with 128 cells. Each cell could be populated with a patch file from the card or internal memory. When the PC message is received, the relevant patch would be loaded based on the look-up table.
This would leave the option to give any name to the patches and it would be flexible.
Iâm running my live set from a Cirklon and itâs programmed to change patches on my instruments when I load the next song. It would be ace if I could do that with the Metamodule too.
actually i do like the lookup table idea for easy organizing/rearranging of a playlist. versus having to tediously rename all the files, like with my original idea. the easiest i could imagine would be a simple txt file that lives in the root of the sdc or usb.. could be called âplaylist.txtâ or whatever. where you simply list the names of the ymls and depending on the line# they live on in the txt, that pcm# would correspond.
dronegen1
weird beat gen 2
sequencerambient 4
pcm1 would load+autoplay dronegen1.yml
pcm3 would load+autoplay sequencerambient 4.yml
etc etc
also ymls for the playlist would probably need to live in a consistent set location such as a folder called autoload (as dan mentioned). or maybe just all in the root folder
also would be cool to have ability to assign channels.. so in the txt you could have sections for channels. would require some parsing magic in the code i guessâŚ
ch1:
dronegen1
weird beat gen 2
sequencerambient 4
For any/omni channel, we could use âAll:â or something.
Plain text is more simple to type but not really more simple to parse, and will be inconvenient if you want to use PC100 or something.
A site like Best YAML Validator Online can verify and clean up yaml if you donât know the syntax. Probably most people will just copy/paste a working example and edit the file names and PC numbers anyways.
Including the drive location (usb, scd, nor) is not totally necessary but without it then the table file would need to scan all disks and possibly pick the wrong one if you have different versions. Or we could force it to only allow loading patches from the same drive as the table file is located
There are some edge cases to consider, mostly dealing with the fact that the table files live on removable drives, there might be one on both SD and USB, and how to handle it if someone modifies the file(s). Preferably itâs not scanning for changes to the file in the background, since that adds a layer of complexity and bus activity itâd be nice to avoid.
Maybe a simple solution is to require you to open the table file from the Patch List in order to activate it. That is, table files would show up in the Patch List page (maybe a different color or icon?). Then if you click on that file, itâll scan it and check for syntax errors or missing patch files, and then a dialog can pop up to let you confirm using this for PC events. If you want to change table files, you can just load a different file. We could even have it automatically load the last table file on boot, like it does for patch files.
love the idea of being able to have multiple table files (also different color so they stand out) so then it doesnât matter if they live on sdc or usb. also, easy nuff imo if they need to be yaml or json format.
and that makes sense on a gap between patches. having a vol ramp down/up between loading definitely seems way better than a rough digital pop