Hi everyone,
I'm loading some MIDI files (format 0) into [cyclone/seq] and saving them to text, I get a series of lines that are 3 or 4 elements long.
The first element seems to be the time (in ms?) at which to play the line, item 3 is the midi note and item 4 is the velocity. I can't find any reference to what item 2 is. The text goes something like this:
0 192 0;
0 144 36 28;
0 192 0;
0 192 0;
7.12308 176 64 127;
61.055 144 36 0;
61.055 144 48 28;
122.11 144 55 25;
253.06 144 55 0;
253.06 144 60 26;
383.483 144 60 0;
383.483 144 62 24;

etc..

Any help would be greatly appreciated, thanks in advance.

@weightless Decimal 144 is 90 in Hex which is the midi note on command for midi channel 1 (0 as channels are 0-15 in midi spec.).
https://people.carleton.edu/~jellinge/m108f13/pages/01/01MIDIBasics.html
176 is B0
B is a control change, so control change channel 1
192 is C0
C is a program change, so program change channel 1
http://www.gweep.net/~prefect/eng/reference/protocol/midispec.html
David.

@weightless You can throw the output of [seq] into [midiparse]. Not sure, if this helps

@whale-av Thanks for the links and info, I'll read it up. but basically it's other midi info like control and program changes?

@ingox Thanks, I think that might help actually. I'm feeding the midi file into a markov chain (adapted from yours, actually ), and I see that's how you did it there. I used text because (a) I thought you couldn't read seq faster than realtime (turns out that's what the message [start 1e+08( does) and (b) I want to treat chords as one item in the markov chain, so it's easier to cluster together notes that happen at the same time by parsing text rather than playing the midi file.
Anyway, I got the patch working, I was just wondering what I was missing in those bytes, but I don't need to store control and program changes.

Thanks for your help!

@weightless Yes, we used [seq] in the same way. The markovGenerator also works with chords as one item, thus it supports polyphonic Markov chains

https://forum.pdpatchrepo.info/topic/10791/markovgenerator-a-music-generator-based-on-markov-chains-with-variable-length

@ingox Oh dear, I'll have to look it up again then. As a matter of fact I'd adapted that patch to do markov chains of letters in written text, and now re-adapted my adapted version rather than going straight to the original. Thanks for mentioning it!

@weightless Yes, now as time has past, i wonder if the markovGenerator could be optimized in several ways. We started with this famous Pd Markov chain tutorial that floats around on the Internet, but it has several flaws, as it is limited to second order Markov chains, skips the first notes and stops if it reaches the end.

In markovGenerator, we implemented a system that can handle chains of any order, incorporates all notes, views the source material as a loop and therefor never stops, and supports polyphony, as it treads chords as one item.

To realize longer chains, all input is encoded as symbols, where "?" is put between notes of one chord and "#" is put between the elements of the chain (if i remember correctly). This way, it is possible to generate the current chain and to search for it in the [text] that holds all chains and the possible follow up notes

The encoding of the inputs as symbols while supporting polyphony and the requirement to view the material as a loop to prevent stopping makes the system a little bit complicated. I wonder if it could be simplified by using indices instead of the full information

This is the famous tutorial, which contains several flaws: http://www.algorithmiccomposer.com/2010/05/algorithmic-composition-tutorial-markov.html

@ingox Thanks for explaining it. By looking at it, I think "?" goes between the elements of the chain (note, velocity etc), whereas "=" between chord notes. I did study it more than a year ago when I made the version for letters, but now I don't remember much. I think reading the patch is quite tricky, but the idea of encoding the inputs as symbols is great and very flexible, a lot better than the tutorial for sure.
There are a few ways it could be simplified, mainly involving the new list store, but as for using indices, I'm not sure I understand what you mean but I think one major downside is that [text search] will only ever return the first match found, not all matches. For this reason I think it would be very tricky indeed to just have the stream of inputs in a text (like the so-called "memory") and do all operation on that.

@weightless Yes, you are probably right. I was thinking about making a simple [markov] object for some time now, which would not support polyphony, but simply creates chains of arbitrary order and treats the material as loop, as mentioned above. With this, anybody could just use Markov chains for any purpose.

To use it with polyphony (chords instead of notes) one would have to outsource the polyphony by collecting the chords in an external lookup [text] and just throw the indices into the [markov] object. So this was the reasoning behind the things i mentioned above.

But if we have this, it wouldn't be necessary to make the chains so complex and maybe it would not even be necessary to encode them as symbols. The benefit of getting rid of the encoding is that in markowGenerator we used [any2symbol] or whatever from zexy or cyclone. The vanilla abstractions by @cuinjune are great, but happend to be too slow at the time for dealing with complete midi files. There has been some development by @Jona and others that would improve the performance, but getting rid of the encoding would speed up everything even more

@ingox I see, well I think a simple [markov] object would be very very useful beyond midi, let's say an object that takes a bang on the left for iterations, a list on the right to make the chain from, and an argument for the order. Perhaps this would be easier to implement, being monophonic. I'll have a think about it.

@weightless Yes, a bang should play the current note and it should not only accept lists but successive notes as source material and then a command to build the chains with a specified order. This way you can for example record a piano progression into [markov], generate the chains and play it

Of course instead of actual notes the input can be arbitrary, so symbols or floats

So the idea is to record the source material (from midi file, live instrument or any other source). From that you can generate the Markov chains. The cool thing about separating the two steps is that you can build the chains with order 2, listen to it, change the order to 8, recreate the chains and listen to the new system without having to record again. So you can play around with different orders. This principle is already implemented in markowGenerator

...

@ingox Yes, very nice ideas. Another idea I was trying to implement is to be able to record parts of the output (let's say the ones that "sound nice") and feed that back as input.

@weightless @ingox this was my second (?) attempt. it is not vanilla and uses a lua dictionary. it just takes simple lists and needs to be modified for midi notes (I did that for .csv files...)
https://forum.pdpatchrepo.info/topic/11864/lua-midi-markov/2
that was a sound result:

@weightless Haha, interesting! This was a discussion i had with @Jona some times: If you take the output of a Markov generator and feed it back as input, no new chains are generated, as all output is already the result of chains that are in the system.

The only thing that changes is the probability that this results are played again in the future. So the system would still gradually change over time, but only slightly. And as we are talking probabilities, it would never be clear if the current result was because of the change or would have happened anyway.

@ingox Yes I agree, if the output is added to the source for the chain, then you only change the probabilities. What I meant is to start with a large pool of data, generate the chain and let it run, and then select bits of the output and replace the original data with those parts, re-compute the chain, run again. In theory this should reduce the possibilities to just those that you selected. Of course you'd be able to do it only so many times before you end up with very few permutations being played out.

@weightless Oh right, yes, this is plausible

This is probably the simplest I can make it for an all-purpose markov chain that does all we've talked about (except my idea to feed back parts of the output). It's still based on @ingox and @Jona patch but it's simpler and all vanilla 0.49.1. It'll need to be tested with some real-life scenarios but at least it's a starting point.

markov.zip