[PD] passing integers

[Orm Finnendahl]

Hi Krzysztof,

Am Samstag, den 19. Januar 2002 um 17:25:44 Uhr (+0100) schrieb Krzysztof Czaja:
>
> 1. 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.
 
> 2. 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