ward de jager

I created a basic sequencer with 3 lanes , gate , velocity and pitch 

When using a make note sending to external hardware the note one and velocity values match up , but as soon as I insert a new gate , the velocity from the previous gate is applied , iow the timing is screwed up

Altough the numeric readout clearly shows they happen at the same time , routing these values to max msp objects to control freq and amp shows they also line up exactly .

So this problem only occurs with midi out

16 stepsmidi out timin.maxpat

1.jpg

I created a basic sequencer with 3 lanes , gate , velocity and pitch  
When using a make note sending to external hardware the note one and velocity values match up , but as soon as I insert a new gate , the velocity from the previous gate is applied , iow the timing is screwed up

Altough the numeric readout clearly shows they happen at the same time , routing these values to max msp objects to control freq and amp shows they also line up exactly  .
So this problem only occurs with  midi out 

I created a basic sequencer with 3 lanes , gate , velocity and pitch  
When using a make note sending to external hardware the note one and 

note-on-and-velocity-don't-match-when-using-midi-out

All right I just solved it by swapping the place of integer modules .

I forgot all about the bottom to top approach 

2.jpg

All right I just solved it by swapping the place of integer modules .
I forgot all about the bottom to top approach 
Cheerio 


What you were experiencing was "right to left".

Do not solve it by moving the boxes graphically on the canvas! Use the most important object in Max: [trigger]. Study Max tutorial #2, #5, you will save time!

No! Forget about "bottom to top".
What you were experiencing was "right to left".
Do not solve it by moving the boxes graphically on the canvas! Use the most important object in Max: [trigger]. Study Max tutorial #2, #5, you will save time!

Yep a trig bang bang , first into velocity ,then pitch

 
Yep a trig  bang bang , first into velocity  ,then pitch 

yeah, a [t b b b] right after the [select] will save you from such errors - and you no longer have to care about the position of things.

and if you still dont get it right for an unknown reason, then check the result you produce by starting from bottom to top: i.e. if the midi output seems wrong, connect a [print] or [message] to the makenote. 


yeah, a [t b b b] right after the [select] will save you from such errors - and you no longer have to care about the position of things.

and if you still dont get it right for an unknown reason, then check the result you produce by starting from bottom to top: i.e. if the midi output seems wrong, connect a [print] or [message] to the makenote. 


From the screenshot you can see that I used a trigger with 3 bangs to trigger midi notes , the rightmost bang ( which I assume is fired of first ) goes in to the length of the note (orange slider ) , the middle bang in velocity (blue slider ) and the leftmost bang into note number .

Does it make sense to use three bangs , or could I just use one trigger (bang ) and wire them up from right to left ? 

I 've got another question 
From the screenshot you can see that I used a trigger with 3 bangs to trigger midi notes  , the rightmost bang ( which I assume is fired of first ) goes in to the length of the note (orange slider ) , the middle bang in velocity (blue slider )  and the leftmost bang into note number .
Does it make sense to use three bangs , or could I just use one trigger (bang ) and wire them up from right to left ? 
I appreciate your time and help 

Leave the triple triggers as they are, they are beautiful. 

And they will always work, regardless how you move the objects around.

Ah, you want your old problem back ;-)
No.
Leave the triple triggers as they are, they are beautiful. 
And they will always work, regardless how you move the objects around.



Pack note, velocity and length into lists

You don't want to send all the values to makenote

when preset gets recalled, or while setting values manually.

I would do this in a different way.
Pack note, velocity and length into lists
and trigger the lists.
You don't want to send all the values to makenote
when preset gets recalled, or while setting values manually.


later, when you want to add saving presets or automation to your GUI sliders you will be happy not to sent bangs to them for the sequencer to play anyway.

if I may tag onto this old post - I have a similar problem in a patch with noteout and the timing of velocity

I'm playing a keyboard with a slider control (like roli) which sends into the patch a midi pitch (on/off) and slider value.

My patch works out the on/off, and maps the slider value to note velocity and periodicity of a repeated note so you get fast/loud and slow/quiet. It should be pretty clear if you turn on the toggle and play with the slider.

Anyhow when playing the keyboard I notice that if I slide to the top to make it fast/loud, stop playing, and then play a new note but starting with my finger low down on the slider, then the patch blurps out a loud note first when it should be quiet. i.e the makenote uses a velocity value from one step behind.

I can't replicate the problem without the instrument just using the patch and looking at things with print, but I can't see how it is the hardware at fault - it must be the patch that's not set up correctly somehow.

I've tried debugging it and notice that the pitch/noteon for makenote comes first before the velocity.

Is there a way in this set up to get the velocity value into makenote before the pitch, so that the new velocity value is always there before the noteon?

Hoping it's a simople fix and I've just lost my marbles a bit :)

it is only a matter if note input reaches your patcher before slider changes the velocity

Your problem seems to be outside of the patcher you posted

it is only a matter if note input reaches your patcher before slider changes the velocity
Your problem seems to be outside of the patcher you posted


thanks - this is what puzzled me because i thought the problem was in the patch.

here is the whole patch where the previous posted patch is a subpatch - would be grateful for any tips. perhaps something which ensures that the slider value update is before the note toggle?

but what I don't get is that if I debug and use watchpoints, the velocity info (point 36) already seems to be before the note toggle (point 38). this is why I thought the issue was in the 'clocker' subpatch

ok this is Live, where one gets trouble with timing.

and what is in that piano notes text file ?

I don't see time relation between output of that which_pitch?

but one would expect that pitch gets in before slider.

udp outputs switch for notes and slider value , or ?

And selected live track recalls pitch and selects which number received 

ok this is Live, where one gets trouble with timing.
why all this many udp ports ?
and what is in that piano notes text file ?

I don't see time relation between output of that  which_pitch?
patcher and udp output.

but one would expect that pitch gets in before slider.
udp outputs switch for notes and slider value , or ?
And selected live track recalls pitch and selects which number received 
from udp port to listen to ?

How should that work timing wise ?


sorry forgot to mention it's in live... udp stuff is a bit of a brute force solution but it works :)

you don't need the text file to debug - just type in a midi pitch number value in the numbox after which_pitch?

there are no time relations between the two bits you mention because the pitch doesn't change. This patch is loaded in several tracks, each with their own (static) pitch (the coll is to associate track number with a pitch), so you can ignore it, I think.

It's just the on/off bit and the slider that are related in time. The udp ports receive a message from a max patch outside of live sending thre values: pitch velocity slider.

In theory the pasted version below is enough to simulate the keyboard input, although i can't get the problem to occur with the velocity value being one step behind the noteon / note trigger

in that case one can reduce your patch to this

image.png

only that osc message is changing, all else is static.

Maybe you need to check makenote repeat modes.

But what on earth forces you to use that many udp ports ?

in that case one can reduce your patch to this


only that osc message is changing, all else is static.
Maybe you need to check makenote repeat modes.
-----
But what on earth forces you to use that many udp ports ?
I simply can't imagine....


note 44 is preselected, and that is what that track - note selector is doing.

emulate key press using space bar while playing with the slider

note 44 is preselected, and that is what that track - note selector is doing.
emulate key press using space bar while playing with the slider


wow - amazing. This is why max forums are a nice place :-)

Thanks - I'll try it out. I didn't know about makenote repeat modes!

ah and the udps... I'm sure there is a better way of doing it but basically I have 40+ instances of the same instrument in live consisting of the clocker patch and then some microtuner and synth stuff.

the keyboard I'm using does polyphony by sending out on channels 1-8, but because live only seems allow m4l to work on one midi channel at a time, I do the channel sorting in a separate max patch which sends the note and slider info into live.

I couldn't work out a more elegant way to get this specific note repeater patch with polyphony and with good synth sounds without simply designating one track per pitch required across multiple duplicate tracks.

Perhaps there is a better way of doing it without the multiple ports like packing everything into one message and getting the m4l to parse, but for the moment this works :-)

It allows any port and channel input directly, and so

you can try imp.midiin
It allows any port and channel input directly, and so
bypasses that stupid live midi limits.



sweet - i didn't know about imp. Will try it out.

sorry this is drifting from the OP but i found out my issue is that the sequence of messages coming out of midiparse in the max patch working as a controller sending info into live isn't working as i need it to with this slider keyboard patch...

you can see in this screengrab video that when i play a note + high slider, release, and then start a new note but with a low slider position (i.e. disjunct values), the pitch + velocity info comes through before the control / slide value, meaning you get a loud+quick blurb note before the slow+quiet note that you expect.

you can see the issue frame by frame in the video at 00:06 there is a tiny moment when the velocity is 77 and the control change is 117 before updating to 0, where my finger really is as i depress the key; I need it to be on 0 or where my finger is as i depress the key.

Brain slightly frazzled but surely this is a trivial issue - how do you get the control / slider value to update before the velocity in this patch?

I thought as with other max objects outlet sequence is right to left, so pitch and velocity should be last(?), unless my subsequent patching is the issue. grateful for any tips again :-)

Screen Recording 2022-08-16 at 23.38.36.mov

I thought as with other max objects outlet sequence is right to left, so pitch and velocity should be last(?), unless my subsequent patching is the issue. grateful for any tips again :-)


The video is huge, visible part tiny, I can't follow anything on it...

I have no idea what your keyboard is sending and in which order.

are midi channels for notes and controller 32 linked in some way ?

I mean are there 8 sliders sending CC 32 on 8 midi channels ?

If so, then route midi channels first, then pack notes and controller together.

You can not expect any order by making such complicated flow.

Can you explain incoming midi a bit more detailed ?

And record short sequence using seq, save as text,

then you can analyse order of received midi messages.

Also post it here, if you want me to have a look at it.

standard tips are not to use gui elements like sliders in path of time sensitive

And to separate (channelyse) incoming data before packing them into lists.

You send OSC, and don't need to follow any midi rules.

In your patch you flood OSC output even while notes are released.

Note ON should grab current assigned slider value and start sending

a list with note number, status (ON - OFF) and 

I'll post few test patches as soon as I get time

The video is huge, visible part tiny, I can't follow anything on it...
I have no idea what your keyboard is sending and in which order.
are midi channels for notes and controller 32 linked in some way ?
I mean are there 8 sliders sending CC 32 on 8 midi channels ?
If so, then route midi channels first, then pack notes and controller together.
You can not expect any order by making such complicated flow.
----------
Can you explain incoming midi a bit more detailed ?
And record short sequence using seq, save as text,
then you can analyse order of received midi messages.
Also post it here, if you want me to have a look at it.
------
standard tips are not to use gui elements like sliders in path of time sensitive
data flow.
And to separate (channelyse) incoming data before packing them into lists.
-----
You send OSC, and don't need to follow any midi rules.
In your patch you flood OSC output even while notes are released.
Note ON should grab current assigned slider value and start sending
a list with note number, status (ON - OFF)  and changed slider values.
on note OFF send list once and stop.

I'll post few test patches as soon as I get time


if you are Mac user this can send and receive test midi data,

simulating 8 channels input via IAC Buss.

Otherwise simply don't use slider randomiser and kslider,

3 parsing options, midiselect, midiparse with 8 gates,

or separate notein and ctlin per channel perform more or less the same.

 object set to pass notes and CC values in a proper way,

output is note number, On Off status (0 - 1), and slider value

now all you need to add is something better than that mess of udp objects....

if you are Mac user this can send and receive test midi data,
simulating 8 channels input via IAC Buss.

Otherwise simply don't use slider randomiser and kslider,
but capture midi keyboard.


3 parsing options, midiselect, midiparse with 8 gates,
or separate notein and ctlin per channel perform more or less the same.
the key is if object set to pass notes and CC values in a proper way,
only when needed.
output is note number, On Off status (0 - 1), and slider value


now all you need to add is something better than that mess of udp objects....


thanks so much! I'm away from the hardware today but will test it out tonight.

granted all the gui stuff should go, and the 

 object looks like it should get around the sync issues with how this keyboard sends through the pitch+velocity values with the slider value not always in the order you expect.

granted all the gui stuff should go, and the if object looks like it should get around the sync issues with how this keyboard sends through the pitch+velocity values with the slider value not always in the order you expect.

looking at the midi as suggested it turns out the hardware I have sends out the previous slider value when you depress the key for a new note before sending the current position.

So I made this patch which might not be the most elegant solution but it works so far. It doesn't pass the slider value if its the same as just before. This means if you go from playing loud (high) to quiet (low) with the slider between different notes separated by a silence, upon the retake for a quiet note you won't hear a loud outburst on the attack as the previous slider value sends through before updating to the new one.

I tried to implement an exception so that if you play a new note with the same slider position as the last note then it should allow it to pass, otherwise when you repeat notes with the same slider position they won't sound.

So I made this patch which might not be the most elegant solution but it works so far. It doesn't pass the slider value if its the same as just before. This means if you go from playing loud (high) to quiet (low) with the slider between different notes separated by a silence, upon the retake for a quiet note you won't hear a loud outburst on the attack as the previous slider value sends through before updating to the new one.

I tried to implement an exception so that if you play a new note with the same slider position as the last note then it should allow it to pass, otherwise when you repeat notes with the same slider position they won't sound.

all you needed in that case is change object

all you needed in that case is change object
at CC value


hmm yeah I tried that but there is something a bit janky with this hardware and how it sends through the touchslider value, so that approach you shared before wasn't working for some reason.

thanks anyway for all this help, really valuable for someone who otherwise tries to avoid working with midi!

hmm yeah I tried that but  there is something a bit janky with this hardware and how it sends through the touchslider value,  so that approach you shared before wasn't working for some reason.

No chance that repeated slider value could pass through change object.

positions, save seq as text and post here.

No chance that repeated slider value could pass through change object.
If it does, or you think it does, 
record few touches from low and high
positions, save seq as text and post here.


NOte on and velocity don't match ( when using midi out )