From Github there is an oopsy hardcoded input method for each daisy provided platform for triggering the change of app in a multi-app. But there doesn’t appear to be a way to do this for the Hothouse pedal or other non-daisy made/custom hardware platforms.
More than one app should work with custom hardware as far as I understand. But similar to those Daisy boards, you’d only be able to switch between apps with MIDI program change messages though, so your custom hardware would need to accommodate for that.
I don’t want to use Midi. I just want to use one of the 3 hothouse switches to move between 3 programs. Can this be exposed in Oopsy, please!
What are the 3 patches that you put together? It should be possible to reroute the input signal between 3 effects using [gate 3].
Each program is a complex combination of effects and the extra effort to manage switching all the controls, etc. … and I’m porting to RNBO to create plugins as well - so, yes it might be possible (though I might also run out of resources), it would be so much easier to manage them separately and switch between them… I imagine the same reasons it is supported in c++
If you can handle doing a custom JSON with C++ insert, the code you need to change apps is not too much. I don’t know what the hothouse target json looks like, but here’s a minimal example (untested, sorry!) of what changing apps in response to a knob might look like:
{
"name": "custom",
"som": "seed",
"defines": {
},
"max_apps": 8,
"audio": {
"channels": 2
},
"inserts": [{
"where": "post_audio",
"code": "if (int(ctrl1) != daisy.app_selected) daisy.schedule_app_load(int(ctrl1));"
}],
"components": {
"ctrl1": {
"component": "AnalogControl",
"pin": 15
}
}
}
1 Like
Thanks. I’ll give that a try. The Hothouse Json is pretty simple (6 knobs, 3/3 position switches, 2 footswitches. 2 LEDs). I haven’t seen the “inserts” define before. That’s super helpful. I wonder if this same technique would work for triggering the system::bootloader mode.
I got this multi-app switching to work: Here’s my insert logic for using a 3 position switch - in the insert.
“inserts”: [{
“where”: “post_audio”,
“code”: “if (int(sw2_up) && daisy.app_selected != 2) daisy.schedule_app_load(2); else if (int(sw2_down) && daisy.app_selected != 0) daisy.schedule_app_load(0); else if (!int(sw2_down) && !int(sw2_up) && daisy.app_selected != 1) daisy.schedule_app_load(1);”
}],
and in Components:
“sw2_up”: {
“component”: “Switch”,
“pin”: 7
},
“sw2_down”: {
“component”: “Switch”,
“pin”: 8
},
do you know how oopys decides the order of multiple gen~ apps listed in daisy.app_selected?
I’m wondering how I can control this so that my default app (hothouse switch not up or down) can definitively control the order of apps mapped to switch.
wow, great thread!
@dlwhite66 great to hear you got it working.
I believe the order is going to be determined by how the find_gens function works in oopsy.snoop.js (in the /javascript folder of the oopsy package). That function walks the Max patcher hierarchy to find any gen~ objects in the same patcher or subpatchers; it uses the built-in methods of the Max js object to walk the patchers (pat.firstobject, obj.nextobject), so the order in which gen~ objects are encountered really depends on how that works. I actually don’t know how it works but I suspect it is probably the same as the ordering of objects in the .maxpat files (which are JSON).
If you wanted to make this more predictable, you could insert some code right after the find_gens call to re-order the cpps array; e.g. sorting it alphabetically via cpps.sort() . If so, make sure you give the gen~ files proper titles (e.g. gen~ @title app1, gen~ @title app2) so that the cpp filenames can be sorted in a controlled way.
[Hmm, maybe having the app names sorted alphabetically by default would be a good idea to have in oopsy in general, since the current ordering is not usefully predictable.]
Graham
1 Like