Forums > MaxMSP

Sending MIDI to poly~ problem

April 19, 2013 | 6:56 pm

It seems I’ve got this series of threads running regarding my struggles with implementing MIDI files.

I want to send the pitch, velocity, and duration values to the poly~ synth. The pitch is no problem but I am not able to get the velocity and duration values to affect the poly~ synth functions/lines. In the following patch I am drawing on Tutorial 19 but can’t really get it to work.

Any input appreciated.

poly~ patch:

– Pasted Max Patch, click to expand. –

top level patch:

– Pasted Max Patch, click to expand. –

April 19, 2013 | 9:12 pm

Is there any reason that you don’t pack the velo and duration into a list for the note message? That way they only go to the proper instance.

If it was me, I would move the mtof into the poly~ patch so that I was throwing around note numbers instead of frequencies, but that’s more a style thing than a functionality thing.


April 19, 2013 | 11:07 pm

Pack them before they get into poly~ and then unpack them inside?

I was just thinking of doing the expr conversion before the poly~ and then sending those into poly~ via a couple if send objects.


April 20, 2013 | 7:36 am

Here’s a stripped down version of your poly patch. Name it cyclesynth_2_(SimpleFM)

– Pasted Max Patch, click to expand. –

and here’s a really stripped down version of your top level patch. This gets rid of detonate and your (I think over-complex) routing scheme in favor of some simple random note generation.

– Pasted Max Patch, click to expand. –

April 20, 2013 | 12:02 pm

Thanks for this Chris. I’ll take a look later. Your simplified midi routing does help clarify it but I still need my "complex" version so I can send out multitrack midi files to the poly~. It;s the best solution I’ve come up with (I even looked at your really nice seqcoll to try and solve my problem) .That way I can control the timbre and amplitude of each track. What I did was based off Tutorial 19 so I had not gone through and cleaned all of it up yet. that patch had those expr objects simultaneously controlling the env and mod index I planned on parsing that data out once I got the thing working. Thanks again for your help. I look forward to getting these working.


April 20, 2013 | 7:01 pm

What I meant when I said "over-complex" is that in your detonate patch you have this array of trackxx patchers all of which do the same thing: send sequence data to the same destinations.

You are packing the info from detonate in a "funny" order, too, which is fine as long as there’s a good reason for it, but I didn’t try and work out what that may be.

If I were you, I would try to define the border between detonate and poly in a more robust manner. I think the rest of the patch would be better served by a well defined fence between the note world and the synthesis world.


April 20, 2013 | 8:39 pm

The multiple patchers in the detonate patch are meant to separate MIDI files according to track. For example, once track 1 gets parsed out I can then send it to the poly~ where it will send it’s own pitch, velocity, and duration info. Perhaps there is a better way to do that, I just don’t know what that is. Perhaps I could send re-pack each track and send that info to poly~ from inside each of the patchers. (here is the original thread where I was trying to work this out : http://cycling74.com/forums/topic.php?id=45464)

The packing order is funny. I first figured this out using note~ but encountered a problem there that prompted me to go back and look at detonate again. I found it easier just to go back and do the funny packing from detonate rather than go and edit each patcher that parsed out the track data.


April 20, 2013 | 11:56 pm

Except you are parsing them all out and then sending them all to the same place, which doesn’t make much sense to me.

Specifically, how do you plan to use tracks & MIDI channels in this patch?


April 21, 2013 | 1:19 pm

"Except you are parsing them all out and then sending them all to the same place, which doesn’t make much sense to me."

Yes, that has been part of the problem I am trying to solve. My goal is to send each track/channel to the poly~ synth individually. Each one has it’s own velocities, durations, etc that I need to control the synth, i.e. I want to send durations, pitches, and velocities from the MIDI file to its own synth so each track is essentially it’s own instrument and the synth will respond accordingly. That’s why I think perhaps I need to send each of the tracks from inside the detonate patch into poly~ straight away rather than piping them back through to the top level patch.


April 21, 2013 | 7:09 pm

OK, here’s your poly patch, this time called cyclesynth_3_(SimpleFM):

– Pasted Max Patch, click to expand. –

And here’s your top level patch, with everything that I didn’t understand stripped out:

– Pasted Max Patch, click to expand. –

April 22, 2013 | 3:18 pm

Thanks for this Chris. Your suggestions have been very helpful.

Your example, as best I can tell though, does not allow each track to be sent out separately from a MIDI file. They all seem to go to the poly~ synth with little control over each track dictating it’s own synth settings. Your patch works great if I want the same general tone for each track but if I want to have the synth change from track to track I think I need to keep each track separate. Your suggestion to use the X1 and X2 parameters is a great idea which I can use to control each instance of the poly~ for just this very purpose.

I have used some of your patch in the following example to output lists into the poly~ synth. My train of thought here is to combine the elements of pitch (integer – the stuff inside the [p pitch] I can put inside the poly if need be), ampndx (list), and modndx (list) (and later add X1 and X2 parameters) into one list and send that combined list into the poly~ synth. Once inside I can then unpack the list according to list/item type and send it where it needs to go.

Problem now is unpacking that list of variable items. I’ve joined them fine but now can’t get them apart. For example ampndx may have 2 items in its list or it may have 6. That can vary so i have prepended each list with an index name which i’d like to unpack later. Not sure if this is the best way to do that.

It could be that I do not need to pack them and just send out individually but that seems to run into the same problem of them going to the same place with no delineation as to which track they belong to and therefore getting undesired random settings.

– Pasted Max Patch, click to expand. –

April 22, 2013 | 8:15 pm

I can’t help but think that this problem is still a little ill-defined. At any rate, here’s cyclesynth_4_(SimpleFM) –

– Pasted Max Patch, click to expand. –

And the top level patch (You could be using completely different synthesizers with this.):

– Pasted Max Patch, click to expand. –

April 22, 2013 | 8:18 pm

You’ve been a great help. The problem is on the user side :P


April 22, 2013 | 8:32 pm

Let me try it this way.

Attached is a midi file I am working with. If you open the file with detonate you’ll see different tracks (not channels). Each track represents a separate instrument, like an orchestra. I want each track sent out to go to its own synth, which is where poly~ comes in. That way each track can have it’s own unique rhythm, timbre controlled via duration, velocity, X1, X2, etc. coming from detonate.

That is why I think I need to take the data parsed out from each track/instrument, such as TRACK 1, and pack that into a list and send it to poly~ via [send]. (That’s what I have been trying today.) Maybe I can’t do that and poly~ needs to be attached with a patch cord.

Does that define the problem a bit more? My brain is mush.

Attachments:
  1. CASCADE1.mid

April 22, 2013 | 8:36 pm

Did you look at my most recent patch?


April 22, 2013 | 8:55 pm

I did but when I play the attached midi file I only get one track out at a time.


April 22, 2013 | 8:59 pm

Oh wait, there were some patch cords not hooked up. Still not getting all tracks though.


April 22, 2013 | 9:02 pm

Inside your [midi-player] each track and it’s corresponding parameters are not getting parsed out into discrete packages are they? It appears everything is just getting packed together regardless of track and sent out. Do I understand that correctly?


April 22, 2013 | 9:33 pm

My latest example does the first four tracks. Adding more is left as an exercise for the user.

All the events from the midi file player have the track number as the first thing in the list. The [route] below the midi file player chops it into individual tracks, and sends the events (minus the track number) to the various synthesizers.


April 22, 2013 | 9:56 pm

I see that now. But the problem I see in that solution is that it would necessitate upwards of 32 synths for 32 tracks defeating the purpose of poly~.


April 22, 2013 | 10:06 pm

poly~ is for managing polyphony, not really for managing multiple timbres. If you really wanted to manage all the timbral diversity inside the poly~ patch, you could use an approach like I posted a couple iterations ago, where the track number was used to make changes inside the poly~ patch. In my example, all I did is set the harmonicity, but in a real patch it could also look up different envelope shapes, set FM depth, etc.


April 23, 2013 | 12:56 am

Maybe this is closer to what you are looking for. This is (unsurprisingly) called cyclesynth_6_(SimpleFM) –

– Pasted Max Patch, click to expand. –

And here’s the top level patch:

– Pasted Max Patch, click to expand. –

The basic idea is that there is a preset per track (utilizing three colls) and when a voice is played, it loads the preset associated with the track. I got bored and only wrote a few presets. The preset UI is pretty crude.


April 23, 2013 | 8:29 pm

That may very well be the solution but it’s still not exactly what I am shooting for.

I’ve done this in another patch with poly~ where I sent [coll] data to [line~]s inside poly~ just as you have done.

What if I applied that same concept to each track though. The first patch shows what each track would receive. The other patch is the poly~ synth that should receive the data from each track (though I have yet to get it to work and my head hurts from trying to figure all this out.)

TRACK to VOICE Patch:

– Pasted Max Patch, click to expand. –

POLY~ Patch that receives TRACK to VOICE data:

– Pasted Max Patch, click to expand. –

April 23, 2013 | 8:47 pm

It’s much easier to pull string than to push string. My patch _has_ a unique setting, per-track. No need to [send] anything or manipulate the target, because the poly~ patch pulls what it needs based on which track it’s played from. Once you write stuff into the colls, on a per-track basis (aka: set up the track presets), the poly~ does the rest, because it knows what track it’s associated with. My patch pulls, your approach pushes.

Pushing (sending) is really messy with poly~ in this case, because you don’t know what poly~ voice is going to be assigned from what track. There’s never going to be a good mapping of tracks -> voices anyway, unless you insure that all your tracks are strictly monophonic, and even then poly will assign voices as they arrive in the time stream.


April 23, 2013 | 8:50 pm

I hear what you’re saying. I think you’re right. All of the MIDI tracks can be monophonic. That really is pretty easy to pull off. But that being said I need to play with your patch some more and see what I come up with.

Thanks much for your help.


April 23, 2013 | 9:00 pm

This doesn’t really apply to your synth, because you scale the envelope time to the duration of the note, but it may be worth noting that making the MIDI tracks monophonic is only half the battle. Even if the MIDI data was monophonic, in a "normal" synth with an ADSR that has a fixed length, if the release time is long enough, an additional voice would be allocated to cover a new note that comes in while the old note is in it’s release phase.


April 24, 2013 | 1:51 pm

After working with this I think I can make this work, Chris.

But this leads me to my next question. Can I edit midi files in Sibelius, Finale, or NoteabilityPro to output the X1 and X2 parameters. It’ll be more efficient for me to edit in there rather than inside detonate.

What I’d like to do is use X1 and X2 to control a coll where I can manipulate harmonicity and fm-depth.

EDIT: I just realized that detonate is not interpreting pitchbend data.


April 24, 2013 | 2:30 pm

Here’s a MIDI file I am testing.

Attachments:
  1. CASCADE1.mid

April 24, 2013 | 6:25 pm

I’ve not really used detonate much, but after a quick spin through the help file, I don’t see a way to map x1 & x2 to things in the MIDI file.

Pitchbend also seems like a no-go.


April 24, 2013 | 7:02 pm

I can go inside detonate and select a region and add an X1 or X2 message to it then "write" that file and it seems to be saved. But that is not very convenient but not the end of the world either.

I think you’re right about pitch bend. I am trying to figure out a work around. Wondering if maybe I can sync up another object that does pull that data off of there and then send that into frequency to get the pitch bend. Just gotta find out how to get that data out. The ajm externals do pull it out but put it into a coll file.


Viewing 30 posts - 1 through 30 (of 30 total)