[PD] passing integers

[Krzysztof Czaja]

hi Orm,

much of what follows is my guesswork, hope it is not completely off
target...

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.  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).

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.  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.  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...

Krzysztof

Orm Finnendahl wrote:
...
> The object, I'm needing it for is the markov object, I mentioned some
> time ago. It stores elements in two data structures: (1.) A table,
> implemented as linked list, which defines the succession of elements
> and (2.) a correlated multidimensional search tree, which stores the
> statistics of occurence of elements of the table in respect to markov
> properties of any order. These statistics can for example be used to
> generate new elements with probabilities which match the current state
> of the table. The table can be extended by supplying elements to the
> object from the outside world, or by the elements generated by the
> object itself, it can be shrunk, manipulated etc...
> 
> The elements to be stored need to have the following properties:
> 
> - They have to be comparable not only for equality, but also, in
>   special cases, whether they lie in a certain range (for example, if
>   you code delta times of performers in real time performances, or if
>   some properties of a complex event should not matter in respect of
>   markov properties, but need to be stored within the element
>   nevertheless)
> 
> - It should be possible to store an element with more than one
>   dimension, for example if you want to store a chord progression
>   including the velocities or delta times.
> 
> The idea, I came up with when I first wrote the object, was, to use
> one 32-bit integer value internally for each element and define it as
> up to 8 bitfields of variable (and userdefinable) width. In practice
> that worked fine even with 32 bits, although sometimes problems arose
> (like if you want to code 5 voice counterpoints including interval
> structure, metrical weight, delta time and tie in information). It
> would probably be nicest, to use pointers as reference to elements of
> arbitrary type instead of integers since the 32 bit limitations could
> be avoided. But then the user would have to provide a function which
> tests for equality, and I have no idea, how this could be done within
> the framework of pd.
> 
> I will probably end up using integers again internally (maybe 64 bits
> instead of 32) and will send a list for storing each element which is
> range checked, length checked and then converted into an integer. But
> if someone has another idea, how to implement this, it would be
> greatly appreciated. As I put in some work, I would really like, if
> the object is considered useful by a lot of people and this is the
> chance to have the object tailored to your own needs.