Triggering chords with MIDI info in [coll]
Hi pals,
I have a couple of MIDI files of simple triad sequences. I've got one (attached) formatted for [coll], and I'm blanking a bit on the best way to send each chord (i.e. group of three lines) from [coll] to three independent [cycle~] objects?
Or maybe I should look at parsing each note in the chord directly from [seq]...
Wrong about that coll is that time position of chords is not stored as index.
Which should be if you want to play that as midi file.
So you first need to dump that into another coll
original :
1, 0 144 54 127;
2, 0 144 59 127;
3, 0 144 62 127;
new :
0 , 54 127 59 127 62 127;
or
0, 54 59 62 127; using only 1 velocity value
for chord off
250, 54 59 62 0;
------------
than it is easy to form that into usable messages to 3 cycle~ objects.
But in first place you have to sort that with coll which is totaly wrong as is.
To add to the problem some chords are triads , the others not ...
47, 2250 144 64 127;
48, 2250 144 66 127;
49, 2500 128 64 0;
50, 2500 128 66 0;
51, 2500 144 52 127;
52, 2500 144 54 127;
53, 2500 144 69 127;
54, 2750 128 52 0;
55, 2750 128 54 0;
56, 2750 128 69 0;
I would say use original midi files play them with seq,
you can use poly~ object with cycle~ voices and adsr~.
----
Or find a better way of storing midi file into coll.
Ok, thanks. I should have mentioned before that this will need to be controlled by [transport] - am I right in thinking [seq] isn't suitable for that?
& do you have any tips for reformatting the messages in [coll] as you outlined?
why should transport be better with coll than with seq ?
How did you intend to drive such formated coll with transport ?
coll would need absolute position in ms.
Would you convert tempo - elapsed raw tick to ms ?
Seq could be driven using tick mesage.
-------
Coll can not use same index several times.
If you look at midi as text file : ( few lines of you coll )
0 144 54 127;
0 144 59 127;
0 144 62 127;
250 128 54 0;
250 128 59 0;
250 128 62 0;
That 's what it would look like if seq opened midi file and stored it as text.
coll would need single value for the time as index, and all midi events
lined up in same line :
0, 144 54 117 144 59 127 144 62 127;
250, 128 54 0 250 128 59 0 250 128 62 0;
-------
Then output would need to run through zl iter 3
to output midi status byte / pitch / velocity trio :
144 54 117
144 59 127
144 62 127
-----
The question is why would you convert midi file into coll in first place ?
What I need is groups of three MIDI numbers to drive three [cycle~] objects at 52bpm. It seems simpler ultimately to be able to trigger each group of three MIDI numbers with [transport]; each beat, or bar, or whatever.
This MIDI file is from the composer's score; they are triads on the score, but as each chord contains 1 or 2 notes from the previous one, I think that is causing the problem you mentioned in your first post.
w/r/t [seq], what I'm confused about is the tick message. The reference says [seq] needs 48 ticks per second, but I'm unsure how to calculate this from a 52bpm clock, so that I get a new chord/group of three notes on each beat, for example.
while it is right that it is more useful to use the time value as index, this wont really work when there is more than one event at the same time.
you rather want to sort things all by time (if you have the chance)
0, 144 54 127 144 59 127 144 62 127;
250, 128 54 0 128 59 0 128 62 0 144 50 127 144 64 127 144 69 127;
500 128 50 0 128 64 0 128 69 0 144 52 127 144 57 127 144 71 127;
when you now call "250" you could get your messages right by
zl iter 3
unpack 0 0 0
the issue which remains is that you would need to run a clock at 1ms here in order to play from this coll.
therefore it might be worth to use delta times, just as real midi does.
p.s.: i totally understand why you want to create your own player using coll, this way one at least knows what is going on. however, in my experience, it will not be less work than using seq or detonate.
Thanks for the info, Roman. Could you also help me with [seq]/tick? If I want it to be synchronised with [transport], do I just send the ticks out of [transport] into [seq], via the tick message?
That doesn't synchronise for me. The midi file plays much too fast, and isn't in time with the transport.
I think I'm going to stick with seq for this, but the files are playing faster than the desired temp (the tempo information in the file is also 52bpm).
better all in one
the patch i posted had mistakes
Wonderful, thank you!
i would also recommend looking into the newly revamped mtr object-
https://docs.cycling74.com/max8/refpages/mtr
i tend to ignore this tick sh*t and i dont use mtr at all.
to find out what resolution the original midi file had, there is (i think) only one way, using [filein] & google for midifile specs. but you cant count on the info from audio or midifiles anyway.
or, when you use detonate, you would insert a multiplicator in the delta time output to change the speed.
Posted this tempo extraction not long ago...