

ingox
@porres Thing is that [markov] is far superior to [anal] + [prob] or [anal] + [markov_matrix] for that matter, so this whole prob matrix approach is going nowhere imho.

ingox
The basic idea is:
 read all the data into a [text]
 choose a random starting point and take the second value of the prob list as current state
 find all lines with the current state as first value, read the second values into a list and the probabilities into an array
 use [array random] and take the corresponding value from the list as new current state
 repeat from step 3.
(In the implementation another column for counting is added, so first value becomes second and so on.)
This should also work with more probabilities and also if the probabilities don't add up to 100. They don't actually have to be percentages at all (untested).

ingox
@porres This uses [array random] to move through the chains:
In markov_matrix_demo.pd you can see that the probabilities actually do match up.
The first value of the prob matrix could also be an index of a larger chain, the second value could also be the index of a chord. This could be incorporated or left outside the object. Only the length of the chain cannot be recalculated from within the system.
This does not include any checks for duplicates or consistency, so [markov_matrix] should be reset first and then the matrix data should be correct.

ingox
@porres Maybe you can post some sample data of your matrix?

ingox
@porres Sure thing, it is public domain.
And yes, this abstraction is basically creating a form of probability matrix out of the source material. If you already have the matrix you don't need most of the steps and can basically directly play the chains...
This abstraction is something like a very basic machine learning approach: Play some notes or read a midi file into it and get new stuff out of it that is computer generated, but based on human creativity.

ingox
@lordgreekfolder Ok, if you start a wiki i provide some patches or something

ingox
@lordgreekfolder Here is an overview: https://puredata.info/community.
Isn't puredata.info already a wiki?

ingox
@BoranRobert Something will always be available: https://web.archive.org/web/*/https://forum.pdpatchrepo.info/

ingox
@sebharmonik.ar Yes. This has been done: https://github.com/puredata/puredata/pull/440.
Anybody with a github account can upvote this or comment.
Here are some more discussions around the topic: https://github.com/puredata/puredata/issues?page=1&q=declare.

ingox
@ddw_music As i have mentioned before here in the forum, this whole complexity should be hidden from the user.
On the other hand, it doesn't really help that we are moaning the situation here in the forum. We should bring this issue to the mailing list, this is the only way to reach the core developers other than to make actual contributions to the code our self. Maybe if the pressure gets strong enough, there will be a solution in the end.


ingox
@mrtunes Or for Gem [declare lib Gem] as long as it is in your path preferences.

ingox
@mrtunes Did you try adding "Gem" to File > Settings > Libraries?

ingox
@zigmhount I believe [pd~] is made to distribute patches among processor cores.

ingox
@jameslo Yes and this is also the case with [receive]. The [receive] created first will get the message first. By using cut & paste you can change the order of receives.

ingox
@jameslo Yes, this is unfortunate.
Another way to approach this, although not really solving the issue, would be to decouple the array the algorithm is operating on from the visual display.
Here i added a second array and the visuals are just performed by pipes: quicksort with delay.pd
So the algorithm is carried out immediately on the first array, but the display on the graphic array is delayed.

ingox
@jancsika @jameslo Here is an implementation of this:
It works, but will freeze the GUI.
Edit: Ah, sorry, just saw that you already did this above...

ingox
@jameslo Yes, sleepsort is the most efficient sort algorithm, it only needs n operations to get the job done, so O(n) maybe.