Kontrol Series Patches


ah - I may have unzipped it over an earlier install - I guess that might do it?


and yes very much enjoying the patches!


yup, that could do it…
(basically it’ll happen if there is any file in the old install, that does not exist in the new install… so is not overwritten)

its something I only recently noticed, and I consider it an OS 3.0 bug, which I’ll fix for the next 3.1 beta.


Ok thanks for the update. I’m still running 3.0 at the moment. Will update to 3.1, I was just being cautious of the betas


Hi, I’m digging your Kontrol concept and format. I really like not having to press buttons to get to the parameter pages, very sharp. Also loving the midi learn implementation. I’ve noticed a couple of things while trying out the midi learn, never sure whether this is user or an actual bug but I’ll throw it out there and let me know what you think. I’ve tried MIDI learn on two Novation controllers, LaunchKey49 and LaunchKey ControlXL, both are having the same issue as follows. When I “learn” a knob and assign it to a parameter it works fine until I reduce the parameter to its lowest value, then it hangs and the parameter won’t respond again until I re-activate it by turning the the corresponding knob on the Organelle. So, for Braids this happens on every parameter except “Shape” on the VCA page. Also, the parameter won’t actually go to 0 it will stop at 0.8% for example on Colour, once I turn the controller to its minimum value it will lose it’s ability to control the parameter until I turn the correct knob on the Organelle. Lastly the “Save Settings” function doesn’t store all the mapping just the controllers for Shape and Transpose on Braids. All the other controllers need to be reset. I don’t know if this is consistent across all of your Kontrol patches, I’ve noticed some similar issues in elements but not to the same extent. I’m running 3.1b3. Thanks for the patches they are great.


thanks for the feedback @squeezed

settings … hmm, i think it does save all the settings - as i tested this very thoroughly on the last release. as the previous release did have issues (not with saving, but the loading) (you definitely have re-downloaded it?)
Im working on the next phase, which is requiring some big changes to the preset saving/loading, so I’ll be testing it again.

midi learn - ok, a key concept here is if you have midi learn active , then if you turn the midi knob to zero, this deletes the assignment. this is quite deliberate to allow a user to not only make new assignments but also delete existing ones :wink:
so this means another thing… the way midi learn is supposed to be used is:

  • activate midi learn
  • turn param on organelle, wiggle midi knob (but not to zero!) (its now assigned)
  • repeat for params/midi knobs
  • deactivate midi learn (!)
  • save settings (optional, if you want to retain across sessions)

the deactivate step is important, otherwise for sure, start twisting the midi control to zero it will un-assign itself.
… from your description this sounds like whats happening.

( i suspect some expect midi learn to auto deactivate, but i dont do this , because i wanted a user to be able to assign lots of controls very quickly without having to keep going back into the menu to activate midi learn again :wink: )

again, as part of the next release I’ll of course be testing it, but I did test it pretty thoroughly on this release, so was pretty sure its was working ok .

perhaps others can comment if they have had similar experiences? as this is the first ive heard of both these issues.


Looking forward to the upcoming release!
I was wondering if Kontrol is going to support a couple of things:
Named parameters values (like being able to see the names of the braids oscillator modes rather than just have numbers). Maybe the patch could send a string back to kontrol that overrides the default display.
I’d also like to be able to turn off the ‘pass through original value’ behaviour for some knobs ( with things like modes or with ranges other than 0-1 as it can be unclear where the actual original position is from the displayed value).


i do want to support this, though probably not next release…

named parameter values - its a bit complex, one of my major aims for Kontrol is to allow remote control of patches - so I can control patches from other devices, like a Push 2, or from a computer via OSC. In this case, the remote control needs to know what the valid values are.
so the way I plan to do this is to create ‘enumerated values’ , these the underlying value will be an integer, but all possible values will be also supplied to the remote control, so it can display the possible values.

Im also wanting to do something similar with resources e.g. wave files… (e.g. im considering a ‘sample’ parameter type) … I really want a sample selection option to be ‘built it’ , perhaps even kits.
(the next release has ‘resources’ but Im only exposing in a very limited form initially)

Id also like a mechanism to allow a particular device to ‘render’ a page as it sees fit,
e.g. enable an ADSR, the values would still be sent, but a special page would be created where the controller could render it as it wants to (eg… graphically)
however, there would still be the option to fallback to the underlying numeric values.
(a bit like how a VST has a custom rendering, but you also get access to the underlying values, vital for automation!)

perhaps you can see from above, its a pretty complex area…

I could take the easy route , and say some patches can override this, and therefore be limited to working on the Organelle, but Im unwilling to do this - Ive bigger plans :wink:

(that said, I might start getting Kontrol to notify the patch of the current page, so theoretically a patcher could just create an empty page, listen for this, and then render directly - however , this is not a practice I would encourage, or use on my own patches)

the passthrough is handled in the Organelle specific code, so if there are various types where this makes sense i could do it BUT honestly, I don’t like inconsistencies in UIs - so Id really like to see a patch/clear use case that shows that the passthrough is inconvenient, to the point that bringing in an inconsistent/new metaphor UI makes sense for the user.

overall - I definitely do want to make the UI more flexible , whilst still retaining a nice consistent UI, and also allow patchers to develop patches quickly (thats the thing Kontrol has quite a few ‘goals’)
… I guess in some ways im playing catch up, given we are starting to get some graphics patches now :slight_smile:

anyway, thats not for the next release, the next release is a pretty fundamental shift to patch development, so Id like to get that in place first (and its nearly finished ;)) , then we can turn to how to make the UI more flexible, to cover more patching needs.

Excitement in the air

Sorry, not tested patches yet, still getting my head round how to work Kontrol into my patches. Only thing I can’t figure out is how to get the patch name to appear in line 2 of the menu? i.e. the “braids” here:

You’re right, this is so much quicker than the alternative (i.e. current) arrangements.


this is the name of the module, and comes from the first parameter passed into KontrolModule.
(the second parameters is the name of the type, and used to find the module definition file)

this is changing a little bit in the next release, and its purpose will become a lot clearer :wink:


Thanks, I will check out double check my process for MIDI learn and get back to you.


Thanks you for your work Technobear ! thoses patches are wonderfull and kontrol’s very convenient.


I thought I had responded but anyway, thanks! Yes you were right I was turning the knob to zero and accidentally un-assigning. Working great now.