Oscillators supporting slides/portamento

#1

I'm trying to find the recommended way to implement a mono patch supporting portamento on overlapping notes (where the second note is offset from the first), since that seems to be a common way to handle portamenti in several hardware MIDI synths. [1]
It seems that default oscillators (sine, square, saw) don't respond to MIDI CC5 (Portamento).
I'm sending two overlapping notes one after another to a monophonic oscillator, but I don't hear any note slide. Is there something I'm missing, or do factory oscillators don't respond to these CC messages? (I'm using the midi/keyb note object as an input to the oscillator).
Should I directly add CC5 modulation to the tuning knob on the oscillator? I suppose not, because it seems more likely this is the role of the pitch bend CC, since the CC message would definitely change the tuning until the next CC5 message, it would not "tune back" to normal once my two notes are over.

I own the Getting Started with Axoloti book by Jan Vantomme, but aside from indicating the CC messages related to portamento (that's where I saw there are 3 dedicated messages to Portamento control, CC5, 65 & 84, but I'm not sure how to use them to get the effect I want, and I'm not even sure which oscillators have support for them) it doesn't describe this matter.

[1] I know of some other synths which have a "global" glide mode, where the synth always remembers the last note played, even after it's OFF, and when a new note arrives it slides from the old note to the new one. That's not what I'm looking for.

#2

factory oscillators don't react to cc5

i have implemented this in several patches, and have posted it in the forum. search for portamento and monophonic in the forums and you should find examples and patches i have done that should get you started ..

#3

here it is: https://sebiik.github.io/community.axoloti.com.backup/t/mono-legato-detecting-overlapping-notes/1780/13?u=lokki

#4

Thanks for the link :slightly_smiling_face:
From what I see this subpatch doesn't handle the CC messages, right? I'm not sure how I would set the glide object to react correctly to them. As such it seems portamento is always activated.

#5

actually it is only enabled when notes overlap, not when you play notes separately. i thought you wanted to adjust the glide time with cc5

#6

Ah okay :slight_smile: I misunderstood the function of the logic/flipflop object in that patch.
The glide time (that I should assign to the math/glide knob I suppose) is usually CC5 or CC84? [1]
So yes it's pretty close but ideally I wanted it to be deactivatable/activatable via CC too (maybe that's the role of CC65), so the same track could be also switching from one note to the next without glissendos at time. But I can work around that by trying to avoid overlapping notes in the cases.
Is there for instance a way to switch between two subpatches (one that would glide and one that would just transmit the note as it is) based on some CC message?

EDITS:
Actually, I'm stupid. I can just get the same effect by setting the math/glide time to zero... But still, if you know how to select a subpatch based on a CC message, I'd be interested for other purposes :slight_smile:

[1] From that thread https://sound.stackexchange.com/questions/44080/midi-how-to-implement-cc-65-c-5-and-cc-84-and-example it seems it's CC5, as CC84 should be a note number (the note from which to glide). Interesting though. I know I don't have to care since I can just use any CC for whatever I want, but I prefer to retain compatibility with other synths just in case.

#7

usually you want both sub patches to run and then you select either one of the outputs with a mux/mux2 object.

you can hook the s input to whatever you like to control the routing.

#8

Okay, I understand. But doesn't it consume resources needlessly given you know you'll only want one subpatch to run at a given time?

#9

yes, it will consume resources.

this is how axoloti works. there is no way to disable a subpatch. the idea being that a patch that compiles and runs on the hardware will never use more then 100% cpu (i.e. because a user enables too many sub patches)

there are ways around this, by creating custom objects that can be enabled/disabled.

but really for this glide thing, i think you can go much simpler and without the need for two separate sub patches, also the resources used should be negligible