btw is the code for KontrolRack / KontrolModule public somewhere?
@oweno of course ⌠all my stuff is open source 
its part of my MEC project
oh right⌠I was looking in the wrong place 
1 Like
Is there a way for a module to know it is about to be unloaded? so, for example, a sequencer module could flush notes before it disappeared.
Iâm adding [r unloadbang-$1] to next release
also (if i remember this time), modules âdown the chainâ will automatically receive an âall-notes-offâ message (ctrl 127) when a module is unloaded.
e.g.
B1->B2->B3->B4
B2 module is changed, B3, B4 will receive âall notes offâ (ctrl 127)
note: Ive already coded all synths to respond to ctrl 127, and if a midi controller sends CC 127
Thanks!
Another question⌠Iâd like to control all the chain output gains in the parallel router from one page, so I donât have to dive into the router module each time. I could modify the router to make a page, but is there a strategy for making a âshortcutâ module that targets params of other modules? I started making a module that adjusts the router chain gains using setparam⌠this works, but I have to hardcode the module slot (works as long as router is in s1), and the parameters get stored twice: by the router and by my module which in turn sets the router. I guess if it works it works, but didnât know if there is a better way
EDIT: To answer my own question, not the best idea to have a parameter of one module directly setting parameter of another module, sorta opens can of worms and overly complicated⌠in this case I just didnât want to change the default router, but doing a custom router with a page for mix or pan or whatever is so much easier. I made a master mix page with all the gains (I made it the first page, so I also had to offset the keyboard page chooser so the first key is actually choosing the second page)⌠works great.
1 Like
Is it possible to make a midi out âoctave-switchableâ module?
Perhaps just channel, velocity, and octave?
apologies for being MIA 
yeah, this is the âstruggleâ with modular,
modules have to be independent - otherwise you start loosing abilities to mix nâ match.
the âexceptionâ is the router, which my definition has to know what modules exists (and the slots) but even it does not know what âtypeâ of module is loaded into a slot.
of course, you could âbreak the rulesâ as long as youâre clear to user what the rules are,
but its not something I can do in the general orac architecture as it would lead to limitations for module developers etc.
glad you found a way to âmake it workâ 
so like the current midi out module, but with the ability to fix the velocity and transpose notes?
sure, you could do this quite easilyâŚ
perhaps a better idea would be to create a separate midi fx though, that changed the data?
so youâd have
seq â notefx â midiout
the advantage of this is you could use it in different scenarios eg.
seq â notefx â basicpoly
I could imagine the module doing all sorts of things like:
scaling velocity, transposing, random/chance
its also a very simple module to write⌠as basically all you are doing is mangling the notes as it goes thru.
(advanced note: in orac 2.0 it can even mangle the channel as this is now part of the note and ctrl messages⌠this is how MPE works in Orac )
1 Like
Is there a reason the module name (or shortend version of it) be prefixed to the parameter names in module.json? most modules have params like âbp_attackâ for basic poly attack, but âattackâ alone would work, right?
1 Like
yeah, no reason at all - they just need to be unique within the module.
I just put up a module demonstrating a graphical page with parameters⌠It is an ADSR that you can adjust on the graphics page (page 1) or on the standard text page (page 2).
https://patchstorage.com/adsr-graphics-demo/
@thetechnobear does this implementation look correct? one thing to note is the knob controls that set the params on the graphics page are bypassing the lock/takeover provided by kontrol, so they jump when touchedâŚbut I guess this mechanism could be added.
3 Likes
yup thatâs exactly what I was trying to describe
it highlights a couple of interesting points to note:
- I think what I need to do in module.json is some how âtagâ the graphics page as organelle specific, and that the âADSRâ page is an alternative âtextâ view. (i.e. the organelle does not need to display the ads page)
- parameters do not have to appear on a page, there can be âhiddenâ parameters
(ones that the patch uses/sets, but the user does not have access to because they are not on a page)
yeah⌠thats an interesting point ⌠this should probably be âconfigurableâ , in some wayâŚ
currently its built on same mechanism as things like OSC and MIDI coming in, and in these circumstances you do not want the take-over functionality.
(e.g. imagine remote automation from midi, it should immediately set value regardless of pot position)
so, the take-over is only required because we are using pots, so its very much hardware specific.
but I think itâd be wise to have some ability to handle this in Kontrol, as its a bit of a pain to implement in PD
3 Likes
Right, mainly I put the second page to test that it was working (i.e. move value on one page, the other page is updating too).
I like the flexibility of this system. It also allows for things like using the knobs to control more than 1 param, or other custom knob to param mappings⌠the jumping values doesnât really bother me, or a takeover mechanism could be added to the patch, been done beforeâŚ
Still wondering: for the simple case like this (1 knob to 1 param), couldnât there be a way to just define one text page and then add a rack message âdisable-display slotID pageâ? So when the module senses the page it just shuts off the usual text display so it can display the graphics. Then the module wouldnât have to bother with setting params, implementing takeover, etc⌠of course you would only want this on Organelle, so the module could also sense if it was running on Organelle and only disable if so.
1 Like
this is really the crux of what I need to figure outâŚ
how does orac have some code thatâs running on some platforms but not others.
ideally this mechanism, would allows for different platforms to have different implementations.
e.g. perhaps a page is marked as an âorganelleâ page, and this causes a particular bit of PD to be loaded? but then there is a fallback page (to display the text parameters)
however, the other displays/controllers I do within MEC, and currently without graphics - so its not quite clear yet - for sure, one possibility is for other displays controllers to follow a similar model (specific osc graphic commands) , and its just MEC that does the rendering etc. (so basically its acting like mother host for other devices)
btw: so how does this all relate to the Organelle? why bother?
so, Im hoping I should get an electra.one quite soon⌠which Iâll be adding Orac support for.
the idea here⌠is if someone wants to âextendâ the UI of the Organelle to something with more encoders and can display more parameters, they can then plug this into their organelle⌠and viola
so, I love that the Organelle is portable/self contained, so can take it out, and play on the sofa.but I also love that when Im using in my little studio, you can connect it up - so, I hook up it up to my mixer, sequencer, midi keyboard and other controllers⌠so now not âlimitedâ by that portable form factor.
1 Like
I guess my thinking was leave it up to the module to sense the platform and act accordingly, then you donât need to add any special organelle page, only the default text page which the module would override (disable-display) if it knew it was running on an OrganelleâŚ
The Electra One looks really cool! How is the parameter display configured, is there some kind of edit process?
hmm, but my thinking is⌠youâd likely want to have some âtextâ parameter pages as well.
i.e. I suspect organelle patches would be a mix of text and graphics.
and when thatâs the case, you need to know the ordering of the pages.
for sure it needs to be different from the current âblank pageâ = you are on you are ownâŚ
and youâre likely right that its going to need a certain amount of pd code controlling whats going on.
generally there is an editor to set it up, and sent to the electra one via usb, the electra one then stores it, so that it can be completely standalone (e.g. with hardware synths)
however, they are working on an api, so that over USB you can reconfigure the display etc.
so the general idea is Mec running on the Organelle will send it the parameters to display, and then route users changes back to orac.
they are keep that the display should be more component based, rather than raw drawingâŚbut are open to more possibility of more components types (e.g. perhaps they could have things like vumeters/adsr/scope?)
I think this is quite a nice approach, since you get a more uniform display, and its easier for things to interact with . (e.g. every app doesnât have to work out how to draw a dial )
right⌠I see how it could get problematic. Anyway, I like the the current approach, it works and is flexible, so maybe just adding an optional platform tag to the pages in module.json is the thing to do (so they can be skipped if not on that platforms). or maybe weâd also need platform exclude tag (i.e. text page excluded on organelle)
Iâm glad to hear they are working on api for the Electra One, and sounds like they have careful thinking about using the components, etc⌠keeps the design and experience unified. how do presets work with something like this? does it need to receive all the params back?
Hi! Iâm attempting to do the same thing with the bpm_seq arper that I did with the original - adding an octave transposition parameter. I think Iâve modified the patch in an equivalent way, but itâs not working I think due to something Iâve got wrong in the json. Hereâs an image:
Guessing the grayed out âintâ is indicative of a problem, though Iâm not sure what/whyâŚ
Missing a comma at the end of the line before the grayed out âintâ
2 Likes
Ha thank you! I saw it just before coming back here, (such an obvious error 
) very much appreciate the kind and quick reply - helped me finish up these mods with confidence