Hi there!
I am patching a first sequencer and I want it polyphonic...
The length of the gate is limited by the square LFO but I'm looking for making kind of chords with longer gates.
I saw here and there some solutions with tables but I am looking for a solution without tables (aiming to save DSP).
How do the gate of midi keyboard objects work because they are able to do so?
I tried something with midi/intern note and a midi /in keyb, but without any result for now!
Thank you for your help!
@Yot Thank you for the advice, now I can hear sound from the midi intern /note!
But, it's still not polyphonic, the next period of the clock cut the previous gate. Unlike the midi keyb.
I've been testing various things with the gate length but each gate is still cut by the next one.
An other way would be; decode the counter into a trig by step, and then an envelope by step?
I don't know anything about code but I guess there is something special with the gate out of the midi/in keyb (or with the subpatch's polyphonic mode).
There are some elements there from @thetechnobear 
https://sebiik.github.io/community.axoloti.com.backup/t/polyphonic-subpatch-not-polyphonic/177
By the way the solution of an oscillator for each step is maybe not too much CPU burdening (regarding to a polyphonic subpatch and my 8 step sequence).
Any idea?
I'm trying to figure out what your specific goal is based off of what's here. It looks as though you want the LFO to advance the steps, and when you play a chord it will stick to that step in the sequence and continue looping, until your limit of 4 note polyphony is exceeded, which is then overdubbed? If I understand correctly then I think the approach needs to be different.
The only way that I can think that you can do this here is with tables, but the good news is that tables aren't as expensive as they seem. You actually determine yourself their size. If you're using a value like pitch you only have to use an 8 bit table because MIDI notes only go between 0-127, a byte can store a value between 0 - 255.
It's also kind of confusing with the Axoloti because DSP, SDRAM, and SRAM are all different. I usually run out of SRAM or SDRAM instead of running out of DSP. My understanding is that SRAM = the amount of RAM on the ARM processor, SDRAM is that slightly smaller chip to the side of the processor which has more capacity, and DSP is the amount of math the CPU can do.
Was this the thread that you saw that included tables?
The other thing that may be helpful is that the blue wires aren't nearly as 'expensive' as the red cables. The blue is 'control rate' while the red is 'audio rate' so there needs to be 16 - 32 bits going much faster to handle audio. Sorry if you knew all this already.
Here check this out. The red rectangle is supposed to be in a subpatch and the rest is supposed to be your main patch, apologies if it's confusing, it would take a lot longer otherwise. I made this using something similar to my multitimbral poly synth, which is why there's 3 notes instead of 4. Just make one more of everything. So you're going to have 2 subpatches in your main patch. The first subpatch with the midi keyboard sends the notes out individually using the polyindex object. It counts which note is being pressed polyphonically and uses it to switch the muxes.
The rest of it goes between the note subpatch and the synth subpatch in the main patch. The blue and yellow inlets will be replaced by the outlets of the note subpatch so you don't need to add them. As noted, it's just there to show you how it's connected. Make sure your note subpatch is on a different MIDI channel than your synth subpatch, and make the midi/inlet/note the same channel as the synth. You still need to put a midi/keybd/in inside of the synth subpatch to receive the notes.
One more thing is to note how everything here is in one ugly line. The execution order of the Axoloti works in a "Z" shape, so you want to make sure that all of the gray bars at the top of each object line up, in order to save more overall SRAM/SDRAM. This is especially important for red cables. If you exceed RAM, move some stuff around, it's hard to tell what will and won't use more RAM so experimentation is key.
Hope that helps.
Some really good info there from Hitachi, particularly how succinctly "Z" sums up Axo execution order.
Just wanted to add something that may be of interest, though this may go further than you need and does deal with table allocations. Rbrt did a hack of how Axo handles polyphony a while back, essentially giving you more control over voice allocation, see this post:
Hello, thank to you too for your useful and extensive answers!
@hitachii I tried something with the tables. The missing part for me was the patch/polyindex object. Unfortunately I can't do what I am aiming to.
What I am looking for is a sequencer that allows to trig gates that last longer than the step itself.
The midi keyboard is not required in itself, I've been looking to it considering that my sequencer should keep a first sound on, while a second, a third etc. are triggered. Musically speaking I would say that I'am looking for long "layers" (in french we say "nappe"). I could do it with a delay too, but I want to have a precise control of the length of each sound. I hope my intention is clearer. (I precise that the length of each voice will be limited by the number of voices and the total length of a cycle of steps.)
Being a noob at patching, I try to figure out how the midi keyboard, being run in a poly subpatch, is able to "pile up" gates without stopping the previous. For example when you maintain a key pressed with infinite sustain! I think there is something to do with this object patch/polyindex.
Another way would be to store a gate length in a table too but I am sure about how to deal with various "gates" merging into a unique envelope. I will try and post a updated patch later.
I am lacking time today but I will see the polyphonic hacking by Robert soon.
Thank you again for your help!
I had a similar Problem once and I used internal MIDI for that.
The sequencer sends note, velocity (must be different from zero) and (short) gate to internal MIDI (Midi/out/note).
The polyphonic sub-patch receives MIDI (midi/in/keyb) and plays each note as long as it wants (I simply turned up the R on the envelope generator).
You can have a blue input of the sub-patch control the duration of the gates, or you can encode the duration into the velocity value, if you want each step to have individual gate length.
That's the key. If this works and you begin running into problems with this, it's because you're exceeding polyphony so you're getting 'voice stealing' which happens in any/every synth once you exceed the voices.
If your entire patch works, everything is doing what you want it to do, and the one singular issue is the voice stealing (the current four note chord 'steals' all the voices from the previous chord), you'll need to multiply your polyphony by the length of your release if that makes sense. This is where you begin eating up memory because there's simply no other way.
When you strum a guitar it has to stop the notes it was playing beforehand because you only have those 6 strings which is the same with synths. Similarly that's why you see synths that have 32 voice polyphony when you only have 10 fingers!
But if you opt to multiply the number of voices then think of it like this. If you have a chord every 2 beats, and your decay time lasts 4 beats, then you'll need 8 voice polyphony so that chord 1 continues when chord 2 plays. Am I understanding the issue?
Also, depending on the patch, I've had success with using a delay or reverb effect to trick the ear for additional polyphony. It usually works pretty good actually!
Yes!
You understood what I am looking for!
But when I gave a try with internal midi gate it was desperately limited by the length of the step.
I 've been testing gate length slowly to be sure to here precisely... And it is no matter of voice stealing here (i tried up even to 8 voices)...
I have no device here, I ll post you a relevant patch soon. I feel like struggling against details! Thank you all for your tips and help.
Of course. You have only one sequencer in your patch, and that sequencer has only one midi/out/note object, so it can only "play" one note at a time.
The polyphonic sub-patch is different: if you set it to 4 voices, the software will generate 4 copies of the subpatch, distribute the MIDI notes among them and combine their audio outputs automatically. So, while one copy still plays the first note, the second copy of the sub-patch can start playing the second note and so on.
The original gate signal still has to be short enough, because with only one midi/out, the first note has to be finished (at the MIDI interface) before the second can start. But the sub-patch can stretch the gate signal or do other things to make the tone longer.
you can also use a demux to send the generated triggers to multiple timers (pulse generator) and internal midi modules and then use a counter to select the next timer&midi module each time a new trigger is played. This way each new trigger will have it's own gate generator. But you'll have to use enough of these for the amount of voices you want to be able to play at the same time and set the amount of voices for the polyphonic subcontainer accordingly.
Hi,
I finally made it with a gate distribution (decoder) and internal midi notes.
In fact I was looking for an object like a voltage control keyboard! Because if I understand the behaviour of the midi/in/keyboard objects they are able to work with multiple gate lengths "out of the box".
@hitachii you got the idea, I knew the trick with a delay but I wanted to play with individual gate duration and now it's working I find it quite fun, and creates a kind of swing feeling.
Thx to all for your support!
Here is the final patch for the next ones who need some pictures to figure out. I finally chose to patch 8 different gates to avoid voice mechanical limitation at the fifth step. I paired velocity to gate length and to a second VCA and it sounds consistent with my initial idea. To be tweaked finer with some math/*C and tests to find the balance.
And the subpatch
Hey that's great, happy to hear you got it working. Does it work the way you wanted it to?
One more thing about the execution order that I would suggest, flip the order of the ctrl/dials with the midi/intern/note so that the note object is underneath the dials. You have the right idea, I should have mentioned that objects going in work best either to the left or above the input object, and objects going out work best to the right or below.
It's fine as it is now, It won't be an issue until your patch starts lookin' like:
