Hi Krzysztof,
Am Samstag, den 19. Januar 2002 um 17:25:44 Uhr (+0100) schrieb Krzysztof Czaja:
- If you are going to use all-in-one markov object, then probably
there is no real need for any coding of the elements, except to speed up the comparisons.
That was the major reason. When I wrote the object, cputime was expensive (my computer had 8MHz clocking) and I was obsessed with efficiency.
If this is not a bottleneck, then just store the elements as arrays of floats packed into a standard struct _elem { struct _elem *next; float data[1]; }. The markov class would accept list messages, and would be instantiated like [markov <ndimensions>]. The main struct of the class would have ``ndimen'' field (and probably also elemsize field added for speed and convenience).
You are absolutely right: Since it is a tree structure, you only need up to 20 comparisons to find any element in a tree with 1000000 elements and therefore it makes perfect sense to use float arrays altogether. But why did you suggest the linked list structure? I guess, a normal array of floats works well, costs less memory space and still can be initialized in the setup function to an arbitrary size.
- But what bothers me most, is whether processing multi-dimensional
real-time performance input without quantizing (possibly vector quantizing) could be useful -- with too broad a sample space one needs huge amount of ``training'' data to start with.
Not really. I attached a markov object to the live performance of an improvising pianist, capturing pitch, velocity and timing and the object could play along in realtime after only a couple of seconds, continuing the stuff of the pianist in much the same manner and style, as he did.
And if there is to be quantizing, then I would rather do it in separate externals or abstractions tuned for any particular domain, not in a generic markov external.
That was the way I used it. Quantization was of course done outside the object.
It may occur, that in most cases such a generic object works best on a small one-dimensional sample space (obtained after vector quantizing), that will fit into undistorted floats...
To store only one dimension is normally not sufficient to capture musical events. It gives a completely different result if you seperate different musical dimensions in different markov objects than combining them in one object. And even if you only use one or two dimensions for comparison (to increase the redundancy), the other information has to stay attached to the element/event. This combining could be done outside the object, but then you need to transfer reliable BIGNUMS to the object, which was the reason for my posting in the first place (see, we are already getting recursive...)
Nevertheless the basic idea of the object is -as you suggest- to have a small but very efficient engine for storing numbers (now: arrays of floats) and retrieving them according to their markov properties of any order, and not so much to have an "all in one" object. For flexibility reasons there has to be some deal of functionality built in which accounts for a lot of messages which can be sent to it. But my goal was to design this object to be quite "pure" in respect to being small, modular and specific in its functionality (in a way like linux and pd ;-) ) as this is how I like things best.
much of what follows is my guesswork, hope it is not completely off target...
Not at all. You obviously got quite a good picture of it and I'm really grateful for the comments as it helps me to view things from a different perspective. In a seperate email I will send the manual of the object to your private email address in case you are interested to get an even better idea and want to help with further suggestions. Anyone who is interested can drop me a note and I will send the manual around.
For all the others: Sorry for spamming this list with lengthy emails.
Gruezi, Orm