Sending MIDI to poly~ problem
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:
top level patch:
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.
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.
Here's a stripped down version of your poly patch. Name it cyclesynth_2_(SimpleFM)
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.
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.
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.
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 : https://cycling74.com/forums/multitrack-midi-or-multiple-midi-files)
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.
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?
"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.
OK, here's your poly patch, this time called cyclesynth_3_(SimpleFM):
And here's your top level patch, with everything that I didn't understand stripped out:
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.
I can't help but think that this problem is still a little ill-defined. At any rate, here's cyclesynth_4_(SimpleFM) -
And the top level patch (You could be using completely different synthesizers with this.):
You've been a great help. The problem is on the user side :P
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.
Did you look at my most recent patch?
I did but when I play the attached midi file I only get one track out at a time.
Oh wait, there were some patch cords not hooked up. Still not getting all tracks though.
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?
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.
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~.
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.
Maybe this is closer to what you are looking for. This is (unsurprisingly) called cyclesynth_6_(SimpleFM) -
And here's the top level patch:
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.
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:
POLY~ Patch that receives TRACK to VOICE data:
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.
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.
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.
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.
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.
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.