Hey,
thanks for your replies! 
Oliver, your right, the text object is actually pretty cool, I didn't know 
about that one. I tested it out a little bit. But writing 60000 rows with 10 
columns into it takes round about 2 minutes on my machine, so that's obviously 
too long :P The possibility to check the completely generated matrix is 
actually more of a comfort thing. We could also use [print] to check if our 
generated probabilities are correct, but seeing everything together is handy. 
Anyhow, opening the gui of [coll] or [text] is not our issue. Our issue is the 
time that it takes to write 60000 rows into these objects. 
I was wondering, if one could do the process of writing into the matrix on 
audio~ level. Don't know if that is possible and if that makes any sense 
though.. I am not that experienced with pd..
Another idea for increasing speed was to use various [zl nth] objects from 
cyclone. One object for each column. I have not tested that yet.
Thanks anyways for the hint on iemmatrix, I did not know about that. And with 
gem, I have not worked yet. I guess, I will take a look at iemmatrix first.

Thank you, Jakob
 
 
 

Gesendet: Samstag, 30. November 2019 um 15:13 Uhr
Von: "oliver" <[email protected]>
An: Pd-List <[email protected]>
Betreff: Re: [PD] writing to cyclone/coll takes a long time
Jakob Laue wrote:
> Dear list,
> For a university project we are building a melody generator based on markov 
> chains. This includes generating a big matrix of probabilities for playing a 
> certain note. The number of rows in the matrix depends on the markov order 
> and the pitch range that our patch works with. We have a pitch range of 9, 
> hence markov order 3 means writing 9^3 rows = 729.
> We want to work with the fifth order which means writing 9^5 = 59049 rows 
> into the matrix. We use the coll object from the cyclone library to generate 
> our matrix because it has the handy gui for looking at your matrix after you 
> generated it.

for what purpose ?

how do you want to "check" 60000 numbers ?

besides that:

1.) there's the vanilla [text] objects that IMHO can handle this sort of
things way better. the advantage to [coll] is that new entries into the
[text] buffer are updated immediately (i.e. you can see the changes when
the [text] window is open as opposed to [coll] where you have to close
and reopen the content window)

2.) even with the [text] objects, opening the content window with a lot
of numbers like your 60000 WILL take a long time anyway, probably even
crash PD. that's a memory thing that very likely applies to the [coll]
object as well. so if you really need to check a specific part of your
big matrix, you should extract a sniplet from it to another smaller
buffer to do so. the help files will help you ;-)

3.) maybe you should use real matrix optimized objects for your task,
like the "IEMMATRIX" library or probably even GEM buffer objects

best

oliver





_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list



_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Reply via email to