Hi!
As someone who is quite familiar with building patches in PD/Max/Axo and now Ksoloti, but with very limited skills in code I am curious.
We have a fantastic number of objects in the library that are mainly limited in their use in hardware DIY-projects etc due to their lack of inlets for either modulation, or to control stuff with midi-assignable controls.
SSS objects are often good examples of this - insanely impressive objects, but sometimes hard to incorporate with control in hardware projects, as they often don’t have inlets for their controls, and have versions of controls that cannot be midi mapped.
Unless someone has a better solution - is there a somewhat comprehensive way of mainly learning to edit objects to add these inlets? Or is every object in code so different, that quite a deep understanding of the code is needed?
Does anyone have other solutions for this problem?
There’s a wealth of relevant information in the forum archive. Unfortunately DuckDuckGo no longer seem to be indexing it so I don’t know how to search it, but this link was easy to find in the user guide section:
Nice one! Indexing sucks really, I have now added a Google search bar in hopes that Google may have been indexing the page by now … and now we have a whopping 7 pages of the whole forum backup indexed and ready to be found!
This was EXACTLY what i needed!
I had already gotten as far as figuring out the inlets etc in object definition edit page, but realised i also need to get into the code.
Massive thanks!
Generally speaking, you can add inlets to just about anything. You’ll have to have a crude understanding of what the inlet value should do. Since you mention SSS’s objects, for example, sss/delay/fifthshifter has a crossover inlet as well as a crossover parameter.
Sure, there are some more advanced things you could do, like clamp the result so it won’t exceed the “Axoloti value” limits: __SSAT(xxx, 28) and __USAT(xxx, 27) (signed saturate and unsigned saturate)
But this is basically how you add inlets.
Whatever inlet name you define in the tab “Inlets” will be accessible in the K-Rate tab and later tabs as “inlet_xxx”.
Same with parameters, and they’ll be “param_xxx”.
Note that there are several cryptic selection values for inlet/outlet types: anything “bool32” is yellow, “frac32.” is blue, “frac32buffer” is red, “int32” is green. “charptr32” is used for strings (pink wires?)
Similar for parameters: “frac32.s” means “signed” knob, i.e. -64.00 to 64.00. In other words, bipolar.
“frac32.u” means “unsigned” so no minus sign, i.e. 0.00 to 64.00. In other words, unipolar.
those “frac32.” types have many different mapping methods, like frac32.s.map.pitch. Those will have different display values attached to them, like “pitch” will alternatively show you frequency in Hz, or MIDI note number, where as “decaytime” will show you the decay time when you connect this knob to an envelope. I don’t believe these types change anything about the raw value of the knob, but maaaybe they do create some sort of “taper” like on real linear or logarithmic pots.
