@ingox Thanks for the patches, I understand what you mean now. This is clever, but if I got it right it means that the markov chain is either monophonic or polyphonic, it can't have a mix of both (how do you tell a single note from a chord index?). In the MarkovGenerator you'd store each event one after the other regardless of whether they are single notes or chords. I think this behaviour is desirable, or at least more flexible.
I've been thinking about this and I reckon the most logical way to approach it would be to first understand what distinguishes a "chord" from a single note, and the difference is that chord notes all happen at the same time. In Pd that's what a list does basically, and so it makes sense to me if an incoming list is interpreted as a chord. This would be the most practical approach. I went a step further and parsed the right inlet this way: lists are always interpreted as chords, a stream of floats and symbols is also interpreted as a list IF there is no delay between the elements (like in an actual midi chord), otherwise they are interpreted as single floats or symbols respectively.
Then in the memory text, only lists are joined together with [vl2s] rather than converting everything to a symbol, this is a good compromise I think. The advantage is that if you don't send any lists at all, the abstraction acts just like the monophonic version (no encoding).
polymarkov.zip
I hope everything works properly, it will require some testing. I've modified a few things including the clip problem, put everything in a gop (makes more sense than using an argument) and added state saving for the texts and order.