Hi all, the other day i had to compare Max and PD again, and it seems that one of PDs core weaknesses is the fact that all messaged operations are happening synchronously, that is, with no respect whether they'll fit into the real-time schedule. A good example is soundfiler, where reading and writing of large files is done in one piece which inevitable leads to audio cracks. In Max for these kind of operations there exists a low-priority message queue (using so-called qelems) which can be used to retrigger an operation that is executed in chunks. These qelems can also be dropped if they are occuring more than once in a queue, or postponed if audio timing needs it. This can't really be done equally in PD by using clock_delay as an alternative. Since PD has a global thread lock now, the other (probably more comfortable) way would be to use threading for longer-lasting operations, and i'd really like to adapt soundfiler and other objects accordingly. The problem with any asynchronous array operation is that there has to be a mechanism to avoid concurrent changing of table sizes by two separate objects (e.g. when one soundfiler is reading data into the array, another one must not resize the same array)... consequently there has to be some kind of "array lock" or even a queue of operations scheduled for execution, because i don't think that operations should just fail... or are there any other ideas how to do it?
best greetings, Thomas
Since PD has a global thread lock now, the other (probably more comfortable) way would be to use threading for longer-lasting operations, and i'd really like to adapt soundfiler and other objects accordingly. The problem with any asynchronous array operation is that there has to be a mechanism to avoid concurrent changing of table sizes by two separate objects (e.g. when one soundfiler is reading data into the array, another one must not resize the same array)... consequently there has to be some kind of "array lock" or even a queue of operations scheduled for execution, because i don't think that operations should just fail... or are there any other ideas how to do it?
i don't know, how the audio arrays are implemented in pd, but it might be useful to use a class similar to c++'s vector class ... if a new operation occurs, such as loading a file with soundfiler, the array 'class' has to allocate a new array, read the soundfile threaded to the new array, and change all pointers to the new array, the old one can be freed now... the problem is, that it's much more difficult to access an array, since all internals/externals would have to refer to the 'array'-class, instead having direct access to the array in memory...
my 2¢...
Tim mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.nyds-exp-discogs.tk -- The only people for me are the mad ones, the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn, like fabulous yellow roman candles exploding like spiders across the stars and in the middle you see the blue centerlight pop and everybody goes "Awww!" Jack Kerouac
Hi Tim, that's exactly what Miller suggested. In PD there's no direct access as an array is addressed by its name (which makes the class you mentioned).
best greetings, Thomas
----- Original Message ----- From: "Tim Blechmann" TimBlechmann@gmx.net To: pd-dev@iem.at Sent: Sunday, December 21, 2003 6:34 PM Subject: Re: [PD-dev] long lasting operations
Since PD has a global thread lock now, the other (probably more comfortable) way would be to use threading for longer-lasting operations, and i'd really like to adapt soundfiler and other objects accordingly. The problem with any asynchronous array operation is that there has to be a mechanism to avoid concurrent changing of table sizes by two separate objects (e.g. when one soundfiler is reading data into the array, another one must not resize the same array)... consequently there has to be some kind of "array lock" or even a queue of operations scheduled for execution, because i don't think that operations should just fail... or are there any other ideas how to do it?
i don't know, how the audio arrays are implemented in pd, but it might be useful to use a class similar to c++'s vector class ... if a new operation occurs, such as loading a file with soundfiler, the array 'class' has to allocate a new array, read the soundfile threaded to the new array, and change all pointers to the new array, the old one can be freed now... the problem is, that it's much more difficult to access an array, since all internals/externals would have to refer to the 'array'-class, instead having direct access to the array in memory...
my 2¢...
Tim mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.nyds-exp-discogs.tk -- The only people for me are the mad ones, the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn, like fabulous yellow roman candles exploding like spiders across the stars and in the middle you see the blue centerlight pop and everybody goes "Awww!" Jack Kerouac
_______________________________________________ PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Sure... just allocate a whole new array in the low priority thread, and then grab the lock only when you're done and ready to switch the new array in place of the old one.
cheers Miller
On Sun, Dec 21, 2003 at 11:51:12AM +0100, Thomas Grill wrote:
Hi all, the other day i had to compare Max and PD again, and it seems that one of PDs core weaknesses is the fact that all messaged operations are happening synchronously, that is, with no respect whether they'll fit into the real-time schedule. A good example is soundfiler, where reading and writing of large files is done in one piece which inevitable leads to audio cracks. In Max for these kind of operations there exists a low-priority message queue (using so-called qelems) which can be used to retrigger an operation that is executed in chunks. These qelems can also be dropped if they are occuring more than once in a queue, or postponed if audio timing needs it. This can't really be done equally in PD by using clock_delay as an alternative. Since PD has a global thread lock now, the other (probably more comfortable) way would be to use threading for longer-lasting operations, and i'd really like to adapt soundfiler and other objects accordingly. The problem with any asynchronous array operation is that there has to be a mechanism to avoid concurrent changing of table sizes by two separate objects (e.g. when one soundfiler is reading data into the array, another one must not resize the same array)... consequently there has to be some kind of "array lock" or even a queue of operations scheduled for execution, because i don't think that operations should just fail... or are there any other ideas how to do it?
best greetings, Thomas
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
-
Miller Puckette -
Thomas Grill -
Tim Blechmann