Merge information from two midi channels together
Hi,
I'd like to make a device that's able to merge midi from two channels together into one.
For example, I have one drum pad at home with which I like to drum in everything. Logically, every line I play on this instrument ends up on one note. In my ideal setup, I'd have a second midi channel with long legato melodic notes which would be sidechained to the single drum channel. The pitch information of this channel would be merged with all the other midi information from the drum channel.
This way, I would be able to drum in melodic lines with a single pad. This would also be handy for live use.
I know it's possible to sidechain midi into a M4L audio effect, is it also possible in a midi effect?
Thanks,
M
If it's okay to run Max in parallel with Ableton Live then it's no problem whatsoever. Your Max patch can receive MIDI information from different channels via a [midiin] object (e.g. to Max 1). You can catch everything that comes into this [midiin] object via a [midiparse] object, ignore the input channels and route it all back into [midiformat] with one fixed channel of your choosing. This [midiformat] then transmits the merged information back into a [midiout] object (e.g. from Max 1) and on the receiving end you just listen to this merged information at the fixed channel.
Drum pads outputs short notes.
How do you want to link velocity and position in timeline of recorded pad
notes to different midi track ?
Have many ... notes listed and just progress, next , next etc ?
or trigger notes which exist in same location using velocity
from pad track ?
How about length of notes ?
Both could be done using 2 m4l devices...
Ah yes @HZ37, I'll check out this option too. Would be to have it run internally in Ableton but since Ableton's API it's not really possible apparently. Perhaps if I'd work with two seperate M4L devices. One which send and one which receives.
Either way, having Max run seperatly is indeed an option. Thanks!
Hi,
I just made a few M4L patches which do the trick. I made two send M4L devices with 'notein' objects that get routed to one receive M4L device which edits the midi. The one added in this post is the receive patch.
Everything "kind of works" but sometimes I get stuck notes. Always at the end of a note. I guess some of the note off's aren't translated really well.
Does anyone know how to fix this?
ps. The number box in there is intented to choose the note's length. So far no good results.
You don't need 3 devices, only 2.
put this into Drum Pad midi track. it sends only note on velocities
if you activate input monitor in Drum Pad track,
you play notes in other track in real time. Otherwise output recorded ones.
place this device into track with long notes.
The long notes track needs no midi input from drum pad.
Received velocities trigger notes.
you can adjust length as usual in makenote.
Hi Source Audio,
Amazing. This works really great. I'm gonna look into attributes and how I can use them. Thanks!
Do you perhaps now of a way to implement a way to edit the drum pad's note length? In the version you made I think it doesn't translate 'note off' information and makes for longer notes than initially played.
Could you maybe explain me how I'm able to implement note off values into this version and alternatively explain me how I can adjust the midi's note lenght? Would be nice to be able to change midi length information from the pad's channel with a knob.
Thanks!
ps. I rebuilt the second patch you sent but I am mostly getting random notes. Must've done something wrong.
martin, I think you'd need a [zl rev] before the [makenote] there.
also, I believe you can skip the [> 0]
last screen shot was only idea how to block drum notes when no long notes are sustaining.
I did not test it at all. one also have to take care of timing between 2 tracks.
idea is to open the gate while note in long notes clip are on, and close it
when they are off.
but as Wetterberg spotted, one mistake was to list in wrong way.
better would be this. (with adjustable note length)
I am used to insert > 0, even that any number higher than 0 would turn gate on directly as well.
You did not explain in detail what you want to use from drum pad notes,
and also not from melody notes in initial post.
I did not expect that you want to use note off from drum pad (being so short),
only velocity and position, and also use last known long note pitch.
Like my first example.
Because that would allow all drum pad notes to produce
notes just as played.
Only note length would be set fixed/adjustable in makenote,
which could also be randomised ?
In case you want both note on and off from drum pad,
simplest is to use makenote again with repeatmode 1 set,
because that would allow to use drum rolls, or better say shorter notes
that note lengths that you might set with that knob you mention.
I think main decision here is to use long notes On/ Off status
or to play last known pitch ?
Hi Source,
Thanks for your response.
I've been using this method for a few days now and am very pleased to say it works really well. A pleasure to work with.
I was wondering however, how can I make this polyphonic? I'd like for the receiving midi channel to have the ability to play chords. I see the 'notein' object is receiving all of the incoming midi notes, but the join object is not transmitting it. What's the fix?
Thanks!
One would need storage of held notes.
Hi, this works wonders (I'm going to backwards analyze all these patches in the future btw)
The only that doesn't work annymore is the input monitoring or live drumming from the other max device. It only works when playing the ableton session, not when input monitoring.
there should be no difference.
As long as there are any held notes in the coll,
r PAD input should trigger them, no matter if from
midi clip, or direct input.
Yeah, I don't know. It does work with the previous receiving patch.
The coll object is receiving way more dumps than it is integers. Could that have something to do with it? For now it's not working.
what do you mean with more dumps ?
I know live sends a lot of note offs,
but notein with velocity > 0 should actually send only
note on messages from drum Pad.
can you post more infos ?
I just tested it in live 11.
No problem, both midi clip and direct midi monitor,trigger notes as expected.
Maybe you have something strange set , like mappings, midi outputs ???
Sending a 'bang' to the 'join' object's left input fixed the issue. I think it's because the right input of the join object isn't a "hot" inlet.
Join receives velocity in right inlet, then coll outputs itered list.
result should be pairs of note - velocity
Hi,
Will go over your answers in details very soon.
This is what my patch looks like right now. I guess it's kind of the same.
you should remove that button that bangs join.
But I can't see what you feed in and out of subpatch.
if you want to have it in a subpatch
Once I remove the bang, the live monitoring doesn't work annymore.
it should , as long as there are any held notes in the coll.
bang to left inlet would repeat last seen single note
no matter if it is held or not.
Hi,
I'd like to add a way to repeat notes in the receive device.
For example, if I play one note on the send channel, I'd like for it to repeat, for example, 3 times. I'd like to be able to control the repeat speed and the amount of times it repeats.
I was thinking to do it with a 'delay' object, or 'tapin~' objects, but I think it'd be hard to control the amount of repeats. Then I was thinking to try it with a 'metro' or 'uzi' object, but I keep bumping into problems regarding data flow etc...
Do you perhaps have any idea on how to implement this?
I was looking into Ableton's 'note echo' object, which has some extra interesting features which I'd like to think about in the future like pitch shifting , but the delay system isn't really what I had in mind since it actually fades like a normal delay. I'd like for my repeat system to kind of act like a delay on full feedback which cuts off every time a certain amount of repeats has been done.
Perhaps it'd be a good idea to implement some sort of sequence instead of a delay. I don't really know which objects to use for this idea though.
Is there some books or youtube channels you can recommend for me to gather these types of information?
Thanks!
I'm working on a new test. Might be able to share it this week.
You stated that my patches don't work for live monitoring.
Is that still so, and if not what was mistake on your side ?
to the repetitions :
it is a logic probem :
what to do when same note comes in before repetitions finish their cycle ?
let's say you have C4 at input and want to repeat it 4 times using 1 quarter note interval,
so you need to start counter for repetitions.
if another C4, or even 5 of them come in before counter ends,
what do you want to do ?
sum all C4 notes at input and multiply by 4 to get total number of repetitions ?
subtract allready performed repetitions untill all are used ?
What about velocity ?
first C4 had 100, next 5 C4 notes 33 48 66 100 120 played as a roll ?
Let's make it more complicated, you had G3 C4 E4 as chord , want to repeat it 6 times,
but then G3 get's triggered 2 times, C4 3 times before chord repetitions finished ?
Midi delay is totaly different than audio delay, because of note numbers and velocities.
Audio simply repeats
This is what I have right now. It repeats perfectly. Do you see room for improvement? I'm already thinking of interesting ways to alter this setup.
The only thing I'd still need is a way to automise the repeat system. I always manually trigger the repeat via the 'live.button' but it'd be handy if I'd also be able to trigger it automatically. Do you have any idea?
I made a small iteration where the feedback repeats now follow the progression on the receiving channel, rather than muddying up the progression with repeats of previous chords.
I realize i basically just made a harmonic metronome... This thing is not really repeating the actual rhythms of the 'send' track...
There's two things I wanna try:
I want to make a version where the repeating mechanism get's triggered with every note from the 'send' track instead of me having to trigger it manually. I have no idea how to do this. I might have to put the repeater in some kind of polyphonic subpatch since there's gonna be overlapping repeats...
I'd like to make an actual delay-like version where the complete rhythm is being delayed rather than the metronome-like style delay I now created. In a way this goes hand in hand with the first point, that is, if I want to have complete control over the amount of repeats per note. If not, a more "standard" delay approach would be necessary. Not some 'counter'-style repeating mechanism.
Any help, tips and useful objects are very welcome!
For whoever's interested.
Your patch is still wrong, it does not respect held notes.
But that seems not to be a probem for you.
Maybe you don't want to respect held notes at all, but punch
last single note left hanging in join object.
you say
"I want to make a version where the repeating mechanism get's triggered with every note from the 'send' track."
what should a note from send track trigger if there are no notes currently held in coll ?
Ony advice I can give you is to first think what you really want, and then look for solutions.
even that sometimes one creates interesting stuff just by experimenting
or making mistakes.
Hi,
Systematically making this patch more useable.
I have one question about the send patch. I'm trying to make it filter notes so that the on velocity is only send when a specific note is playing. I made this idea:
But this seems to not work with Max's logic. It only plays when playing the desired note, which is good, but then when I play a next wrong note, it also plays the first strike of the wrong note. After playing the wrong note for a while and play the right note after, it skips the first right note and starts to play from the second one.
I'm guessing this has something to do with Max's order of reading objects. Any idea's on how to patch this correct?
it is not problem of Max logic, but your construct.
And the reason is that you don't read help files of objects you use.
if you want to pass only single note, use match or routepass
or even midifilter.
But simplest is this - matches note 38
Hi,
attached is one out of 3 receiving patches. I stopped working on it because it kinda does what I was aiming for. However, there's some things that could be done better/more professional.
Now when it opens, I have to click the note lenghts a couple of times before it plays the selected note lenghts. This could probabaly be fixed with some 'loadmess' objects
I was thinking that it would be nice to be able to split extra functions into new M4L devices. Now i tried implementing a sort of note repeater and velocity -> note length modulation but 75 procent of the time, I'm not persé using these options. Instead of having objects loaded and using CPU, it would be handy to split all these individual functions into smaller M4L objects, creating this sort of modular system. I can't yet wrap my head around how to do this though. Do any of you know?
About the note repeater: it would be great if I could be able to have every note repeated a certain amount of times with a certain repetition rate. In some way this has to be coded in a polyphonic structure, because notes will be overlapping. At least, that's what I'm thinking right now. This doens't have to part of the initial receiver patch, but now it does use some information from some of the objects in the receiver and sending patch. If anyone has any idea, let me know.
Also, if anyone is interested in switching this conversation to either whatsapp or discord, I would love to. I'm really looking for one on one quick back and forth patching ideas. This forum is amazing, but I'd like to have a quicker and less formal way of socializing about coding.
Thanks
stuff that works in max does not necessary work in m4live.
all that Live GUI elements with parameter mode and init vaules
enabled could easily disturb loadbang values,
but maybe you should simplify and make this patchers seen
on the screenshot below work properly.
Either insert init values or loadmess values,
and make sure that end result gets output whenever any of the input
selectors change.
here you can see fixed FilterGate :
and VelLength:
and so on ....
I don't think I can help you much when it comes to live, simply because I don't use it.
If few delays or repetitions create strain or cpu load ?
I mean if it makes more sense to use several devices with again own ID's, parameters etc
instead of packing stuff into single device ?
No idea, but genearally I would do all in one, because
it is easier to control the flow, and maybe bypass other routing problems in Live.
But most strain is created using inefficient patching.
repeating multiple notes of same pitch which overlap to same destination
make no sense to me.
I woud rather check repeat modes of makenote to see if you can get
wanted resut.
... sorry , I am not taking part on any social media discussions or platforms.
Hi,
Thanks for your answers. Very interesting insight in the enclosed patchers.
About the repeating/delaying: what do you think about the test I made on the right side of the patcher? The idea is to not have a delay-sounding repetition but rather a straight forward repetition of played notes with the correct velocity. You'd have the ability to choose the amount of repetitions.
So you'll have to build somethinf that recognizes every note being playef, repeats it a certain amount of times at the same velocity as the played note and then stops. I think it'll have to be a poly situation because there will be multiple repetitions happening at once.
Think of it as a digital delay like repetition but where you just have the ability to choose the amount of repetitions.
Thanks!
As I allread mentioned :
if same note arrives before repetitions have ended, you have
to decide what to do with them all.
In order to repeat individual notes, you will need
separate output - one makenote can not deal with it so easy.
what if you play fast roll - 6 same notes of different velocities in short time
and set to repeat 4 times ?
Is there some documentation of how much or how fast the makenote object can process information? How much is too much?
Is it possible to have multiple makenote objects in a project? Could you describe how this would be set up in this specific situation?
That being said, perhaps I'll be able to code something that all notes with a distance of less than a certain amount of milliseconds will not retrigger, resulting in fast drum rolls not being triggered by the repeater.
Best would be for you to test part by part
how that snippets you want to make should work.
I think you are not aware what problems you run into when using velocity to set note length,
then repeat that notes using which length ?
Check how makenote behaves when it has notes in the "to do" list
when it receives new length arguments.
you can have as many makenote objects in your patch as you want,
but they all will output to same midi destination in Live,
how do you control the flow ?
and many other logical problems, like note as part of a chord or single one, rolls etc, just to mention few of them.
How do you count repetitions per note ?
collect and add ALL same pitched notes to repeat list, and output them untill they all get output ?
How about changing delay time and repeat count on the fly which is automated in your patch ?
If you ask me, I would start repetitions only if note does not get in for delay time interval,
or in simple words only last note gets repeated, and repetitions stop if same note gets in
before all repetitions were played.
Kind of ducking delay.
You will need one instance of counter, delay or whatever you use for repetitions for
each note number.
Alright,
These are all interesting ideas, thank you.
What I'm indeed struggling with the most right now is how I'm gonna count the repetitions per note... There's multiple ways how this could play out... Do you have any idea/proposal? Perhaps based on the idea I already made?
Thanks
I would use poly~ set to number of maximum expected voices.
then target poly instances based on midi note offset.
have look at this single note duck delay example .
It works as I described in my earlier post.
click as many times on note 44 / velocity 112 as you want,
after no input for set delay time, repetitions will start.
Note length is set to 250,
but all parameters, like
Delay On/Off, Delay Time, Number of Repetitions and Note Length
can be sent generally for or poly instances, or calculated per instance ...
Actually one could do without poly, with hard wired routing,
one note number - one subpatch.
Hi Source,
Once again, huge thank you. I'm gonna go over the things you said in the near future. For now I'm just stress testing this thing and putting it into practice.
One option I've been meaning to implement is to have the option to use the note off information of the harmonic receiving channel. This way I'd be able to use the piano roll a bit better and use sustain and decay on synthesizers more efficiently.
Here's a part of the patch again. I tried adding an 'if' object but instead of stopping the note, it just retriggers it. I don't understand since I'm sending a 0 velocity with the note...
Also, sorry if it sound as if I'm posting questions too soon without doing my own reseach, but I'm having issues printing and monitoring my M4L patches when working on them. Whenever I open one of the receiving patches while the project is running, that specific object stops working correctly and and restrains itself from being looked at via the console or message boxes... Extremely annoying. Have you had this problem before? Seems like a major bug. Perhaps it has something to do with the sending & receiving between two patches within an ableton project? It seems that the debugging features shows information on the cables of the receiving channel, but not the sending channel...
The only thing I'm trying to do is basically send one note off signal when the midi note on the harmonic channel stops. In the current setup, it retriggers a note. I don't think this has anything to do with the repeatmode.
If I remember correctly,
you are sending only note on from source PAD track.
At one point you asked for note filter, what is source patch looking like now ?
And ... you are still triggering non existing notes in target track.
I mean last note left hanging in join object from coll.
Maybe I misunderstood what you want to trigger,
I thought only currently held notes in the track,
which are existing in coll should get triggered by
input from PAD track.
.............
now this :
"I'm trying to do is basically send one note off signal
when the midi note on the harmonic channel stops"
if harmonic channel means notes from playback track
then you need to use note off
from that track, not from PAD input.
Hi Source,
By removing the bang connected to the 'join' object and implementing your '$1 0' message box, I was able to get the result that I'm looking for.
However, when removing the 'bang', the target track doesn't respond to the midi note being played on the send track, making it impossible to use these objects in a live situation. I had the same problem before in the beginning of this thread. I tried changing the 'join' object with a 'pak' object, but that results in more wrong triggering. I'm gonna dive a bit deeper into the logic of this patch today.
Do you perhaps have any experience/ had similar problems with the M4L problem I explained in my previous post?
No, it is very simple and logical.
coll holds pitches of currently held notes.
When PAD sends velocity, it triggers the notes from the coll
using dump message.
I have tested that in very beginning of this thread.
I don't know what your problem is ?
using join or pack should not make any difference,
but not pak
iter is also not needed, because you insert notes
into coll as single items, not as list.
Hi,
Thanks for your answer.
I removed the Iter object, I already figured it didn't really serve a function now. I read all of the help files of the objects you used by the way.
The problem is that I am not able to trigger notes live... When I send a note on the send channel, containing the sending M4L object, it does not trigger a note in the 'target' track... Therefore, no live triggering works. This used to work when having a bang connected the the 'join' object, although this resulted in other unwanted issues.
I also noticed that in the current configuration the target object sometimes bugs out and sustains notes indefinitely. After some time it then automatically restores to normal. Strange. Could it be that M4L sometimes freezes up and has this sort of issues or are there ways to code these bugs out?
I am not really using live and can't tell much about it's problems.
If you monitor input in target device, without
triggering anything, you'd find out what the problem is,
at least if target receives notes as expected.
did you set 2 tracks as I posted some time ago,
disabling midi input on target track . and also
disabling output from PAD track ?
if Pad track is set to input monitor, it should
send notes to target when played live
Hi Source,
Thanks for your reply once again.
I feel stupid now, Apparently I only tested the object with the input monitoring set to auto. When the bang is connected, which is the case in the two different receiving objects, they also receive midi when the channel is set to auto. When you remove the bang the monitoring has to be set to 'in' to work.
Will be using the device and learn about your coding as I go along. Will refer to this forum post when I come up with something new. Thank you once again for your help! Your contribution was of great value.
Ok, now the mistery is unveiled, all this time I was wondering
why you get no input in target when input monitor is on.
One thing you asked about : target device getting stuck...
I am not sure if send / receive data flow is running in high priority thread
within Live.
Midi should, but it also suffers from audio settings - latency.
I know nothing about performance in Live.
P.S.
could you upload short midi clip with your pad recorded,
containning few notes an few fast rolls ?
it makes me wonder how long notes are, and if overlapping could cause
additional problems.