David,
One thing I attempted and couldn't find a solution for was the following, mostly owing to the limitation of interfacing with a 64 sample block size.
I wanted to have a directory of hundreds of audio recordings. Each one would be a single wavelength from an interesting sound, like a bass clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end at a zero crossing so you could chain them together to make complex timbres. They could be chained in sequence, randomized, or loaded in meta-data-matched chunks. I ran into a problem figuring out how to trigger the next sound based on the ending of the last sound in a sample accurate way. Sound file loading or even buffer playback triggering waits until the start of the next block size before it updates. If you have a waveform that lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before the next waveform would start. Not only do you not get the continuous sound you want, this winds up creating a periodic pattern with a frequency of 689 Hz (44100/64).
David, I like your idea "what (if anything) someone tried to do in Pd, but couldn't given its limitations". I think this could be a wonderful challenge if we could have a monthly thread like this where the best minds among us come up with solutions to some of the hardest conceptual challenges in Pd.
I'm still struggling with loading dozens of files, audio dropouts, and other similar problems. Someone else expressed frustration about Pd's single-threaded status. I too have feared upgrading my computer based on the limitations of current multicore processors (although realistically I think we can all look at the "turbo-boost" level or whatever Intel calls it to determine where our processor might run with a demanding patch. I understand the fact that you can't run your audio process on multiple cores, because it is a linear process. It would be great if the GUI could run on a second core, a process that loads audio into memory could run on third core, while GEM could automatically run on a fourth core. I don't have any concept of how feasible that would be, though. Does the GUI in pd-l2orc run on a separate core?
Sam
Message: 4 Date: Tue, 23 Feb 2016 09:01:06 -0800 From: david medine dmedine@ucsd.edu
One thing I'd be interested in knowing about is what (if anything) someone tried to do in Pd, but couldn't given its limitations (apart from look/feel/convenience issues).
Does the GUI in pd-l2orc run on a separate core? For all versions of Pd, the GUI runs as a separate process. It communicates with the Pd process over a TCP socket. -Jonathan
On Tuesday, February 23, 2016 1:51 PM, Samuel Burt <composer.samuel.burt@gmail.com> wrote:
David, One thing I attempted and couldn't find a solution for was the following, mostly owing to the limitation of interfacing with a 64 sample block size. I wanted to have a directory of hundreds of audio recordings. Each one would be a single wavelength from an interesting sound, like a bass clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end at a zero crossing so you could chain them together to make complex timbres. They could be chained in sequence, randomized, or loaded in meta-data-matched chunks. I ran into a problem figuring out how to trigger the next sound based on the ending of the last sound in a sample accurate way. Sound file loading or even buffer playback triggering waits until the start of the next block size before it updates. If you have a waveform that lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before the next waveform would start. Not only do you not get the continuous sound you want, this winds up creating a periodic pattern with a frequency of 689 Hz (44100/64). David, I like your idea "what (if anything) someone tried to do in Pd, but couldn't given its limitations". I think this could be a wonderful challenge if we could have a monthly thread like this where the best minds among us come up with solutions to some of the hardest conceptual challenges in Pd. I'm still struggling with loading dozens of files, audio dropouts, and other similar problems. Someone else expressed frustration about Pd's single-threaded status. I too have feared upgrading my computer based on the limitations of current multicore processors (although realistically I think we can all look at the "turbo-boost" level or whatever Intel calls it to determine where our processor might run with a demanding patch. I understand the fact that you can't run your audio process on multiple cores, because it is a linear process. It would be great if the GUI could run on a second core, a process that loads audio into memory could run on third core, while GEM could automatically run on a fourth core. I don't have any concept of how feasible that would be, though. Does the GUI in pd-l2orc run on a separate core? Sam
Message: 4 Date: Tue, 23 Feb 2016 09:01:06 -0800 From: david medine dmedine@ucsd.edu
One thing I'd be interested in knowing about is what (if anything) someone tried to do in Pd, but couldn't given its limitations (apart from look/feel/convenience issues).
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
This is doable, actually, but not easy. [delay] and [vline~] both have subsample accuracy. It would be substantially easier if you could preprocess and deliver the sequence as one big message dump to [vline~]. If you loaded all of the files into one array (up to about 6:20 of audio at 44100) and kept tabs on where each one started and how long it was in samples and milliseconds, you could then feed [vline~] into [tabread~] to play the relevant chunk of the array. If you needed to be able to transpose them, that's a little harder because depending on how long the table was, you'd need to work in the message onset to [tabread4~]'s right inlet or face index degradation.
On Tue, Feb 23, 2016 at 1:40 PM, Samuel Burt <composer.samuel.burt@gmail.com
wrote:
David,
One thing I attempted and couldn't find a solution for was the following, mostly owing to the limitation of interfacing with a 64 sample block size.
I wanted to have a directory of hundreds of audio recordings. Each one would be a single wavelength from an interesting sound, like a bass clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end at a zero crossing so you could chain them together to make complex timbres. They could be chained in sequence, randomized, or loaded in meta-data-matched chunks. I ran into a problem figuring out how to trigger the next sound based on the ending of the last sound in a sample accurate way. Sound file loading or even buffer playback triggering waits until the start of the next block size before it updates. If you have a waveform that lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before the next waveform would start. Not only do you not get the continuous sound you want, this winds up creating a periodic pattern with a frequency of 689 Hz (44100/64).
David, I like your idea "what (if anything) someone tried to do in Pd, but couldn't given its limitations". I think this could be a wonderful challenge if we could have a monthly thread like this where the best minds among us come up with solutions to some of the hardest conceptual challenges in Pd.
I'm still struggling with loading dozens of files, audio dropouts, and other similar problems. Someone else expressed frustration about Pd's single-threaded status. I too have feared upgrading my computer based on the limitations of current multicore processors (although realistically I think we can all look at the "turbo-boost" level or whatever Intel calls it to determine where our processor might run with a demanding patch. I understand the fact that you can't run your audio process on multiple cores, because it is a linear process. It would be great if the GUI could run on a second core, a process that loads audio into memory could run on third core, while GEM could automatically run on a fourth core. I don't have any concept of how feasible that would be, though. Does the GUI in pd-l2orc run on a separate core?
Sam
Message: 4 Date: Tue, 23 Feb 2016 09:01:06 -0800 From: david medine dmedine@ucsd.edu
One thing I'd be interested in knowing about is what (if anything) someone tried to do in Pd, but couldn't given its limitations (apart from look/feel/convenience issues).
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I guess I've never seen a way to load multiple samples into a single array. That might solve another problem I'm currently sorting out. How do you do that?
Sam
On Tue, Feb 23, 2016, 1:56 PM Matt Barber brbrofsvl@gmail.com wrote:
This is doable, actually, but not easy. [delay] and [vline~] both have subsample accuracy. It would be substantially easier if you could preprocess and deliver the sequence as one big message dump to [vline~]. If you loaded all of the files into one array (up to about 6:20 of audio at 44100) and kept tabs on where each one started and how long it was in samples and milliseconds, you could then feed [vline~] into [tabread~] to play the relevant chunk of the array. If you needed to be able to transpose them, that's a little harder because depending on how long the table was, you'd need to work in the message onset to [tabread4~]'s right inlet or face index degradation.
On Tue, Feb 23, 2016 at 1:40 PM, Samuel Burt < composer.samuel.burt@gmail.com> wrote:
David,
One thing I attempted and couldn't find a solution for was the following, mostly owing to the limitation of interfacing with a 64 sample block size.
I wanted to have a directory of hundreds of audio recordings. Each one would be a single wavelength from an interesting sound, like a bass clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end at a zero crossing so you could chain them together to make complex timbres. They could be chained in sequence, randomized, or loaded in meta-data-matched chunks. I ran into a problem figuring out how to trigger the next sound based on the ending of the last sound in a sample accurate way. Sound file loading or even buffer playback triggering waits until the start of the next block size before it updates. If you have a waveform that lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before the next waveform would start. Not only do you not get the continuous sound you want, this winds up creating a periodic pattern with a frequency of 689 Hz (44100/64).
David, I like your idea "what (if anything) someone tried to do in Pd, but couldn't given its limitations". I think this could be a wonderful challenge if we could have a monthly thread like this where the best minds among us come up with solutions to some of the hardest conceptual challenges in Pd.
I'm still struggling with loading dozens of files, audio dropouts, and other similar problems. Someone else expressed frustration about Pd's single-threaded status. I too have feared upgrading my computer based on the limitations of current multicore processors (although realistically I think we can all look at the "turbo-boost" level or whatever Intel calls it to determine where our processor might run with a demanding patch. I understand the fact that you can't run your audio process on multiple cores, because it is a linear process. It would be great if the GUI could run on a second core, a process that loads audio into memory could run on third core, while GEM could automatically run on a fourth core. I don't have any concept of how feasible that would be, though. Does the GUI in pd-l2orc run on a separate core?
Sam
Message: 4 Date: Tue, 23 Feb 2016 09:01:06 -0800 From: david medine dmedine@ucsd.edu
One thing I'd be interested in knowing about is what (if anything) someone tried to do in Pd, but couldn't given its limitations (apart from look/feel/convenience issues).
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
If you're using the newest vanilla, the [array] object lets you get a range of a given size from an index onset as a list, and to put the list at an onset of another array. It's faster than I thought it would be. So, you could just load your files sequentially into one table and copy them from there, or you could load them all into their own table and copy each one separately. I don't know which would be faster. As long as you're not resizing the table each time you load, I'd probably go with the first option. Just remember that [soundfiler] runs synchronously, so you don't want to do any of this in the middle of the operation.
On Tue, Feb 23, 2016 at 2:49 PM, Samuel Burt <composer.samuel.burt@gmail.com
wrote:
I guess I've never seen a way to load multiple samples into a single array. That might solve another problem I'm currently sorting out. How do you do that?
Sam
On Tue, Feb 23, 2016, 1:56 PM Matt Barber brbrofsvl@gmail.com wrote:
This is doable, actually, but not easy. [delay] and [vline~] both have subsample accuracy. It would be substantially easier if you could preprocess and deliver the sequence as one big message dump to [vline~]. If you loaded all of the files into one array (up to about 6:20 of audio at 44100) and kept tabs on where each one started and how long it was in samples and milliseconds, you could then feed [vline~] into [tabread~] to play the relevant chunk of the array. If you needed to be able to transpose them, that's a little harder because depending on how long the table was, you'd need to work in the message onset to [tabread4~]'s right inlet or face index degradation.
On Tue, Feb 23, 2016 at 1:40 PM, Samuel Burt < composer.samuel.burt@gmail.com> wrote:
David,
One thing I attempted and couldn't find a solution for was the following, mostly owing to the limitation of interfacing with a 64 sample block size.
I wanted to have a directory of hundreds of audio recordings. Each one would be a single wavelength from an interesting sound, like a bass clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end at a zero crossing so you could chain them together to make complex timbres. They could be chained in sequence, randomized, or loaded in meta-data-matched chunks. I ran into a problem figuring out how to trigger the next sound based on the ending of the last sound in a sample accurate way. Sound file loading or even buffer playback triggering waits until the start of the next block size before it updates. If you have a waveform that lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before the next waveform would start. Not only do you not get the continuous sound you want, this winds up creating a periodic pattern with a frequency of 689 Hz (44100/64).
David, I like your idea "what (if anything) someone tried to do in Pd, but couldn't given its limitations". I think this could be a wonderful challenge if we could have a monthly thread like this where the best minds among us come up with solutions to some of the hardest conceptual challenges in Pd.
I'm still struggling with loading dozens of files, audio dropouts, and other similar problems. Someone else expressed frustration about Pd's single-threaded status. I too have feared upgrading my computer based on the limitations of current multicore processors (although realistically I think we can all look at the "turbo-boost" level or whatever Intel calls it to determine where our processor might run with a demanding patch. I understand the fact that you can't run your audio process on multiple cores, because it is a linear process. It would be great if the GUI could run on a second core, a process that loads audio into memory could run on third core, while GEM could automatically run on a fourth core. I don't have any concept of how feasible that would be, though. Does the GUI in pd-l2orc run on a separate core?
Sam
Message: 4 Date: Tue, 23 Feb 2016 09:01:06 -0800 From: david medine dmedine@ucsd.edu
One thing I'd be interested in knowing about is what (if anything) someone tried to do in Pd, but couldn't given its limitations (apart from look/feel/convenience issues).
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
One great advantage of maxmsp is gen, which gives you sample-level patching with the possibility of a one-sample delay.
P
On Tuesday, February 23, 2016, Samuel Burt composer.samuel.burt@gmail.com wrote:
David,
One thing I attempted and couldn't find a solution for was the following, mostly owing to the limitation of interfacing with a 64 sample block size.
I wanted to have a directory of hundreds of audio recordings. Each one would be a single wavelength from an interesting sound, like a bass clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end at a zero crossing so you could chain them together to make complex timbres. They could be chained in sequence, randomized, or loaded in meta-data-matched chunks. I ran into a problem figuring out how to trigger the next sound based on the ending of the last sound in a sample accurate way. Sound file loading or even buffer playback triggering waits until the start of the next block size before it updates. If you have a waveform that lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before the next waveform would start. Not only do you not get the continuous sound you want, this winds up creating a periodic pattern with a frequency of 689 Hz (44100/64).
David, I like your idea "what (if anything) someone tried to do in Pd, but couldn't given its limitations". I think this could be a wonderful challenge if we could have a monthly thread like this where the best minds among us come up with solutions to some of the hardest conceptual challenges in Pd.
I'm still struggling with loading dozens of files, audio dropouts, and other similar problems. Someone else expressed frustration about Pd's single-threaded status. I too have feared upgrading my computer based on the limitations of current multicore processors (although realistically I think we can all look at the "turbo-boost" level or whatever Intel calls it to determine where our processor might run with a demanding patch. I understand the fact that you can't run your audio process on multiple cores, because it is a linear process. It would be great if the GUI could run on a second core, a process that loads audio into memory could run on third core, while GEM could automatically run on a fourth core. I don't have any concept of how feasible that would be, though. Does the GUI in pd-l2orc run on a separate core?
Sam
Message: 4 Date: Tue, 23 Feb 2016 09:01:06 -0800 From: david medine <dmedine@ucsd.edu javascript:_e(%7B%7D,'cvml','dmedine@ucsd.edu');>
One thing I'd be interested in knowing about is what (if anything) someone tried to do in Pd, but couldn't given its limitations (apart from look/feel/convenience issues).
Le 24/02/2016 16:50, peiman khosravi a écrit :
One great advantage of maxmsp is gen, which gives you sample-level patching with the possibility of a one-sample delay.
you can use [block~ 1 1 1] in a pd subpatch.
cheers c
P
On Tuesday, February 23, 2016, Samuel Burt <composer.samuel.burt@gmail.com mailto:composer.samuel.burt@gmail.com> wrote:
David, One thing I attempted and couldn't find a solution for was the following, mostly owing to the limitation of interfacing with a 64 sample block size. I wanted to have a directory of hundreds of audio recordings. Each one would be a single wavelength from an interesting sound, like a bass clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end at a zero crossing so you could chain them together to make complex timbres. They could be chained in sequence, randomized, or loaded in meta-data-matched chunks. I ran into a problem figuring out how to trigger the next sound based on the ending of the last sound in a sample accurate way. Sound file loading or even buffer playback triggering waits until the start of the next block size before it updates. If you have a waveform that lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before the next waveform would start. Not only do you not get the continuous sound you want, this winds up creating a periodic pattern with a frequency of 689 Hz (44100/64). David, I like your idea "what (if anything) someone tried to do in Pd, but couldn't given its limitations". I think this could be a wonderful challenge if we could have a monthly thread like this where the best minds among us come up with solutions to some of the hardest conceptual challenges in Pd. I'm still struggling with loading dozens of files, audio dropouts, and other similar problems. Someone else expressed frustration about Pd's single-threaded status. I too have feared upgrading my computer based on the limitations of current multicore processors (although realistically I think we can all look at the "turbo-boost" level or whatever Intel calls it to determine where our processor might run with a demanding patch. I understand the fact that you can't run your audio process on multiple cores, because it is a linear process. It would be great if the GUI could run on a second core, a process that loads audio into memory could run on third core, while GEM could automatically run on a fourth core. I don't have any concept of how feasible that would be, though. Does the GUI in pd-l2orc run on a separate core? Sam Message: 4 Date: Tue, 23 Feb 2016 09:01:06 -0800 From: david medine <dmedine@ucsd.edu <javascript:_e(%7B%7D,'cvml','dmedine@ucsd.edu');>> One thing I'd be interested in knowing about is what (if anything) someone tried to do in Pd, but couldn't given its limitations (apart from look/feel/convenience issues).--
*www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk http://peimankhosravi.co.uk/miscposts.rsshttp://spectralkimia.wordpress.com/*
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You can do this with MSP's poly~ too but I'm guessing that the CPU costs are quite heavy. Moreover, there are operators in gen that are designed for low-level operations.
*www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk http://peimankhosravi.co.uk/miscposts.rss http://spectralkimia.wordpress.com/*
On 24 February 2016 at 16:15, cyrille henry ch@chnry.net wrote:
Le 24/02/2016 16:50, peiman khosravi a écrit :
One great advantage of maxmsp is gen, which gives you sample-level patching with the possibility of a one-sample delay.
you can use [block~ 1 1 1] in a pd subpatch.
cheers c
P
On Tuesday, February 23, 2016, Samuel Burt < composer.samuel.burt@gmail.com mailto:composer.samuel.burt@gmail.com> wrote:
David, One thing I attempted and couldn't find a solution for was thefollowing, mostly owing to the limitation of interfacing with a 64 sample block size.
I wanted to have a directory of hundreds of audio recordings. Eachone would be a single wavelength from an interesting sound, like a bass clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end at a zero crossing so you could chain them together to make complex timbres. They could be chained in sequence, randomized, or loaded in meta-data-matched chunks. I ran into a problem figuring out how to trigger the next sound based on the ending of the last sound in a sample accurate way. Sound file loading or even buffer playback triggering waits until the start of the next block size before it updates. If you have a waveform that lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before the next waveform would start. Not only do you not get the continuous sound you want, this winds up creating a periodic pattern with a frequency of 689 Hz (44100/64).
David, I like your idea "what (if anything) someone tried to do inPd, but couldn't given its limitations". I think this could be a wonderful challenge if we could have a monthly thread like this where the best minds among us come up with solutions to some of the hardest conceptual challenges in Pd.
I'm still struggling with loading dozens of files, audio dropouts,and other similar problems. Someone else expressed frustration about Pd's single-threaded status. I too have feared upgrading my computer based on the limitations of current multicore processors (although realistically I think we can all look at the "turbo-boost" level or whatever Intel calls it to determine where our processor might run with a demanding patch. I understand the fact that you can't run your audio process on multiple cores, because it is a linear process. It would be great if the GUI could run on a second core, a process that loads audio into memory could run on third core, while GEM could automatically run on a fourth core. I don't have any concept of how feasible that would be, though. Does the GUI in pd-l2orc run on a separate core?
Sam Message: 4 Date: Tue, 23 Feb 2016 09:01:06 -0800 From: david medine <dmedine@ucsd.edujavascript:_e(%7B%7D,'cvml','dmedine@ucsd.edu');>
One thing I'd be interested in knowing about is what (if anything) someone tried to do in Pd, but couldn't given its limitations(apart from look/feel/convenience issues).
--
*www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk < http://peimankhosravi.co.uk/miscposts.rss%3E< http://spectralkimia.wordpress.com/%3E*
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Are there any other DSP environments besides ChucK that don't block audio? Last time I tried ChucK (2012?) its efficiency was still abysmal. [block~ 1] definitely takes a hit, but it's usually possible to minimize how much of the DSP chain is actually blocked at 1. I guess with Csound you can specify a k-rate equal to the sample rate which is also effectively a single sample block. I haven't ever used Csound in a real-time context, and most of what I do with it compiles much more slowly than real time in any case.
On Wed, Feb 24, 2016 at 1:44 PM, peiman khosravi peimankhosravi@gmail.com wrote:
You can do this with MSP's poly~ too but I'm guessing that the CPU costs are quite heavy. Moreover, there are operators in gen that are designed for low-level operations.
*www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk http://peimankhosravi.co.uk/miscposts.rss http://spectralkimia.wordpress.com/*
On 24 February 2016 at 16:15, cyrille henry ch@chnry.net wrote:
Le 24/02/2016 16:50, peiman khosravi a écrit :
One great advantage of maxmsp is gen, which gives you sample-level patching with the possibility of a one-sample delay.
you can use [block~ 1 1 1] in a pd subpatch.
cheers c
P
On Tuesday, February 23, 2016, Samuel Burt < composer.samuel.burt@gmail.com mailto:composer.samuel.burt@gmail.com> wrote:
David, One thing I attempted and couldn't find a solution for was thefollowing, mostly owing to the limitation of interfacing with a 64 sample block size.
I wanted to have a directory of hundreds of audio recordings. Eachone would be a single wavelength from an interesting sound, like a bass clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end at a zero crossing so you could chain them together to make complex timbres. They could be chained in sequence, randomized, or loaded in meta-data-matched chunks. I ran into a problem figuring out how to trigger the next sound based on the ending of the last sound in a sample accurate way. Sound file loading or even buffer playback triggering waits until the start of the next block size before it updates. If you have a waveform that lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before the next waveform would start. Not only do you not get the continuous sound you want, this winds up creating a periodic pattern with a frequency of 689 Hz (44100/64).
David, I like your idea "what (if anything) someone tried to do inPd, but couldn't given its limitations". I think this could be a wonderful challenge if we could have a monthly thread like this where the best minds among us come up with solutions to some of the hardest conceptual challenges in Pd.
I'm still struggling with loading dozens of files, audio dropouts,and other similar problems. Someone else expressed frustration about Pd's single-threaded status. I too have feared upgrading my computer based on the limitations of current multicore processors (although realistically I think we can all look at the "turbo-boost" level or whatever Intel calls it to determine where our processor might run with a demanding patch. I understand the fact that you can't run your audio process on multiple cores, because it is a linear process. It would be great if the GUI could run on a second core, a process that loads audio into memory could run on third core, while GEM could automatically run on a fourth core. I don't have any concept of how feasible that would be, though. Does the GUI in pd-l2orc run on a separate core?
Sam Message: 4 Date: Tue, 23 Feb 2016 09:01:06 -0800 From: david medine <dmedine@ucsd.edujavascript:_e(%7B%7D,'cvml','dmedine@ucsd.edu');>
One thing I'd be interested in knowing about is what (ifanything) someone tried to do in Pd, but couldn't given its limitations (apart from look/feel/convenience issues).
--
*www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk < http://peimankhosravi.co.uk/miscposts.rss%3E< http://spectralkimia.wordpress.com/%3E*
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
My original point is that there is gen~ within maxmsp: https://www.youtube.com/watch?v=7iiekKzFstU
*www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk http://peimankhosravi.co.uk/miscposts.rss http://spectralkimia.wordpress.com/*
On 24 February 2016 at 19:27, Matt Barber brbrofsvl@gmail.com wrote:
Are there any other DSP environments besides ChucK that don't block audio? Last time I tried ChucK (2012?) its efficiency was still abysmal. [block~ 1] definitely takes a hit, but it's usually possible to minimize how much of the DSP chain is actually blocked at 1. I guess with Csound you can specify a k-rate equal to the sample rate which is also effectively a single sample block. I haven't ever used Csound in a real-time context, and most of what I do with it compiles much more slowly than real time in any case.
On Wed, Feb 24, 2016 at 1:44 PM, peiman khosravi <peimankhosravi@gmail.com
wrote:
You can do this with MSP's poly~ too but I'm guessing that the CPU costs are quite heavy. Moreover, there are operators in gen that are designed for low-level operations.
*www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk http://peimankhosravi.co.uk/miscposts.rss http://spectralkimia.wordpress.com/*
On 24 February 2016 at 16:15, cyrille henry ch@chnry.net wrote:
Le 24/02/2016 16:50, peiman khosravi a écrit :
One great advantage of maxmsp is gen, which gives you sample-level patching with the possibility of a one-sample delay.
you can use [block~ 1 1 1] in a pd subpatch.
cheers c
P
On Tuesday, February 23, 2016, Samuel Burt < composer.samuel.burt@gmail.com mailto:composer.samuel.burt@gmail.com> wrote:
David, One thing I attempted and couldn't find a solution for was thefollowing, mostly owing to the limitation of interfacing with a 64 sample block size.
I wanted to have a directory of hundreds of audio recordings. Eachone would be a single wavelength from an interesting sound, like a bass clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end at a zero crossing so you could chain them together to make complex timbres. They could be chained in sequence, randomized, or loaded in meta-data-matched chunks. I ran into a problem figuring out how to trigger the next sound based on the ending of the last sound in a sample accurate way. Sound file loading or even buffer playback triggering waits until the start of the next block size before it updates. If you have a waveform that lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before the next waveform would start. Not only do you not get the continuous sound you want, this winds up creating a periodic pattern with a frequency of 689 Hz (44100/64).
David, I like your idea "what (if anything) someone tried to do inPd, but couldn't given its limitations". I think this could be a wonderful challenge if we could have a monthly thread like this where the best minds among us come up with solutions to some of the hardest conceptual challenges in Pd.
I'm still struggling with loading dozens of files, audio dropouts,and other similar problems. Someone else expressed frustration about Pd's single-threaded status. I too have feared upgrading my computer based on the limitations of current multicore processors (although realistically I think we can all look at the "turbo-boost" level or whatever Intel calls it to determine where our processor might run with a demanding patch. I understand the fact that you can't run your audio process on multiple cores, because it is a linear process. It would be great if the GUI could run on a second core, a process that loads audio into memory could run on third core, while GEM could automatically run on a fourth core. I don't have any concept of how feasible that would be, though. Does the GUI in pd-l2orc run on a separate core?
Sam Message: 4 Date: Tue, 23 Feb 2016 09:01:06 -0800 From: david medine <dmedine@ucsd.edujavascript:_e(%7B%7D,'cvml','dmedine@ucsd.edu');>
One thing I'd be interested in knowing about is what (ifanything) someone tried to do in Pd, but couldn't given its limitations (apart from look/feel/convenience issues).
--
*www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk < http://peimankhosravi.co.uk/miscposts.rss%3E< http://spectralkimia.wordpress.com/%3E*
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
i think there's noyhing in gen that you cant do in pd, it has a small set of objects, but i guess the deal is that it, somehow, makes it more efficient, that's all.
i've started studying max/msp recently, and i've found many things lacking in it, more than i would've thought, by the way.
cheers
2016-02-24 16:39 GMT-03:00 peiman khosravi peimankhosravi@gmail.com:
My original point is that there is gen~ within maxmsp: https://www.youtube.com/watch?v=7iiekKzFstU
*www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk http://peimankhosravi.co.uk/miscposts.rss http://spectralkimia.wordpress.com/*
On 24 February 2016 at 19:27, Matt Barber brbrofsvl@gmail.com wrote:
Are there any other DSP environments besides ChucK that don't block audio? Last time I tried ChucK (2012?) its efficiency was still abysmal. [block~ 1] definitely takes a hit, but it's usually possible to minimize how much of the DSP chain is actually blocked at 1. I guess with Csound you can specify a k-rate equal to the sample rate which is also effectively a single sample block. I haven't ever used Csound in a real-time context, and most of what I do with it compiles much more slowly than real time in any case.
On Wed, Feb 24, 2016 at 1:44 PM, peiman khosravi < peimankhosravi@gmail.com> wrote:
You can do this with MSP's poly~ too but I'm guessing that the CPU costs are quite heavy. Moreover, there are operators in gen that are designed for low-level operations.
*www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk http://peimankhosravi.co.uk/miscposts.rss http://spectralkimia.wordpress.com/*
On 24 February 2016 at 16:15, cyrille henry ch@chnry.net wrote:
Le 24/02/2016 16:50, peiman khosravi a écrit :
One great advantage of maxmsp is gen, which gives you sample-level patching with the possibility of a one-sample delay.
you can use [block~ 1 1 1] in a pd subpatch.
cheers c
P
On Tuesday, February 23, 2016, Samuel Burt < composer.samuel.burt@gmail.com mailto:composer.samuel.burt@gmail.com> wrote:
David, One thing I attempted and couldn't find a solution for was thefollowing, mostly owing to the limitation of interfacing with a 64 sample block size.
I wanted to have a directory of hundreds of audio recordings. Eachone would be a single wavelength from an interesting sound, like a bass clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end at a zero crossing so you could chain them together to make complex timbres. They could be chained in sequence, randomized, or loaded in meta-data-matched chunks. I ran into a problem figuring out how to trigger the next sound based on the ending of the last sound in a sample accurate way. Sound file loading or even buffer playback triggering waits until the start of the next block size before it updates. If you have a waveform that lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before the next waveform would start. Not only do you not get the continuous sound you want, this winds up creating a periodic pattern with a frequency of 689 Hz (44100/64).
David, I like your idea "what (if anything) someone tried to do inPd, but couldn't given its limitations". I think this could be a wonderful challenge if we could have a monthly thread like this where the best minds among us come up with solutions to some of the hardest conceptual challenges in Pd.
I'm still struggling with loading dozens of files, audio dropouts,and other similar problems. Someone else expressed frustration about Pd's single-threaded status. I too have feared upgrading my computer based on the limitations of current multicore processors (although realistically I think we can all look at the "turbo-boost" level or whatever Intel calls it to determine where our processor might run with a demanding patch. I understand the fact that you can't run your audio process on multiple cores, because it is a linear process. It would be great if the GUI could run on a second core, a process that loads audio into memory could run on third core, while GEM could automatically run on a fourth core. I don't have any concept of how feasible that would be, though. Does the GUI in pd-l2orc run on a separate core?
Sam Message: 4 Date: Tue, 23 Feb 2016 09:01:06 -0800 From: david medine <dmedine@ucsd.edujavascript:_e(%7B%7D,'cvml','dmedine@ucsd.edu');>
One thing I'd be interested in knowing about is what (ifanything) someone tried to do in Pd, but couldn't given its limitations (apart from look/feel/convenience issues).
--
*www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk < http://peimankhosravi.co.uk/miscposts.rss%3E< http://spectralkimia.wordpress.com/%3E*
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
This doesn't answer Matt's question at all (apologies), but just as a clarification, ChucK /does /block audio. It's just that ChucK always blocks at the minimum size of 1 sample per block. 1 is still a block size though, and it still implies the same problems associated with order of operations, feedback, interpolating control input, and parallelization that a block size of 64 does.
Also, maybe this has already been pointed out on this thread, but block 1 is super slow because it means that you have to load all your DSP functions onto the CPU cache every 1/SR seconds instead of 64/SR seconds. Blocking by 64 buys a lot. Having a locally adjustable block size is a great feature (that ChucK lacks) because you can do it for special needs cases (like variable delay patches, for example).
Anyway, in my opinion, the block thing isn't a limit to Pd, but a limit to real-time digital signal processing.
On 2/24/2016 11:27 AM, Matt Barber wrote:
Are there any other DSP environments besides ChucK that don't block audio? Last time I tried ChucK (2012?) its efficiency was still abysmal. [block~ 1] definitely takes a hit, but it's usually possible to minimize how much of the DSP chain is actually blocked at 1. I guess with Csound you can specify a k-rate equal to the sample rate which is also effectively a single sample block. I haven't ever used Csound in a real-time context, and most of what I do with it compiles much more slowly than real time in any case.
On Wed, Feb 24, 2016 at 1:44 PM, peiman khosravi <peimankhosravi@gmail.com mailto:peimankhosravi@gmail.com> wrote:
You can do this with MSP's poly~ too but I'm guessing that the CPU costs are quite heavy. Moreover, there are operators in gen that are designed for low-level operations. *www.peimankhosravi.co.uk <http://www.peimankhosravi.co.uk> * On 24 February 2016 at 16:15, cyrille henry <ch@chnry.net <mailto:ch@chnry.net>> wrote: Le 24/02/2016 16:50, peiman khosravi a écrit : One great advantage of maxmsp is gen, which gives you sample-level patching with the possibility of a one-sample delay. you can use [block~ 1 1 1] in a pd subpatch. cheers c P On Tuesday, February 23, 2016, Samuel Burt <composer.samuel.burt@gmail.com <mailto:composer.samuel.burt@gmail.com> <mailto:composer.samuel.burt@gmail.com <mailto:composer.samuel.burt@gmail.com>>> wrote: David, One thing I attempted and couldn't find a solution for was the following, mostly owing to the limitation of interfacing with a 64 sample block size. I wanted to have a directory of hundreds of audio recordings. Each one would be a single wavelength from an interesting sound, like a bass clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end at a zero crossing so you could chain them together to make complex timbres. They could be chained in sequence, randomized, or loaded in meta-data-matched chunks. I ran into a problem figuring out how to trigger the next sound based on the ending of the last sound in a sample accurate way. Sound file loading or even buffer playback triggering waits until the start of the next block size before it updates. If you have a waveform that lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before the next waveform would start. Not only do you not get the continuous sound you want, this winds up creating a periodic pattern with a frequency of 689 Hz (44100/64). David, I like your idea "what (if anything) someone tried to do in Pd, but couldn't given its limitations". I think this could be a wonderful challenge if we could have a monthly thread like this where the best minds among us come up with solutions to some of the hardest conceptual challenges in Pd. I'm still struggling with loading dozens of files, audio dropouts, and other similar problems. Someone else expressed frustration about Pd's single-threaded status. I too have feared upgrading my computer based on the limitations of current multicore processors (although realistically I think we can all look at the "turbo-boost" level or whatever Intel calls it to determine where our processor might run with a demanding patch. I understand the fact that you can't run your audio process on multiple cores, because it is a linear process. It would be great if the GUI could run on a second core, a process that loads audio into memory could run on third core, while GEM could automatically run on a fourth core. I don't have any concept of how feasible that would be, though. Does the GUI in pd-l2orc run on a separate core? Sam Message: 4 Date: Tue, 23 Feb 2016 09:01:06 -0800 From: david medine <dmedine@ucsd.edu <mailto:dmedine@ucsd.edu> <javascript:_e(%7B%7D,'cvml','dmedine@ucsd.edu <mailto:dmedine@ucsd.edu>');>> One thing I'd be interested in knowing about is what (if anything) someone tried to do in Pd, but couldn't given its limitations (apart from look/feel/convenience issues). -- *www.peimankhosravi.co.uk <http://www.peimankhosravi.co.uk> <http://www.peimankhosravi.co.uk> <http://peimankhosravi.co.uk/miscposts.rss><http://spectralkimia.wordpress.com/>* _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
OK, now I'm having trouble even imagining how an unblocked audio model could possibly behave (at least, as David points out, in a real-time context).
On Wed, Feb 24, 2016 at 2:58 PM, David Medine dmedine@ucsd.edu wrote:
This doesn't answer Matt's question at all (apologies), but just as a clarification, ChucK *does *block audio. It's just that ChucK always blocks at the minimum size of 1 sample per block. 1 is still a block size though, and it still implies the same problems associated with order of operations, feedback, interpolating control input, and parallelization that a block size of 64 does.
Also, maybe this has already been pointed out on this thread, but block 1 is super slow because it means that you have to load all your DSP functions onto the CPU cache every 1/SR seconds instead of 64/SR seconds. Blocking by 64 buys a lot. Having a locally adjustable block size is a great feature (that ChucK lacks) because you can do it for special needs cases (like variable delay patches, for example).
Anyway, in my opinion, the block thing isn't a limit to Pd, but a limit to real-time digital signal processing.
On 2/24/2016 11:27 AM, Matt Barber wrote:
Are there any other DSP environments besides ChucK that don't block audio? Last time I tried ChucK (2012?) its efficiency was still abysmal. [block~ 1] definitely takes a hit, but it's usually possible to minimize how much of the DSP chain is actually blocked at 1. I guess with Csound you can specify a k-rate equal to the sample rate which is also effectively a single sample block. I haven't ever used Csound in a real-time context, and most of what I do with it compiles much more slowly than real time in any case.
On Wed, Feb 24, 2016 at 1:44 PM, peiman khosravi <peimankhosravi@gmail.com
wrote:
You can do this with MSP's poly~ too but I'm guessing that the CPU costs are quite heavy. Moreover, there are operators in gen that are designed for low-level operations.
*www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk *
On 24 February 2016 at 16:15, cyrille henry < ch@chnry.netch@chnry.net> wrote:
Le 24/02/2016 16:50, peiman khosravi a écrit :
One great advantage of maxmsp is gen, which gives you sample-level patching with the possibility of a one-sample delay.
you can use [block~ 1 1 1] in a pd subpatch.
cheers c
P
On Tuesday, February 23, 2016, Samuel Burt < composer.samuel.burt@gmail.com mailto:composer.samuel.burt@gmail.com> wrote:
David, One thing I attempted and couldn't find a solution for was thefollowing, mostly owing to the limitation of interfacing with a 64 sample block size.
I wanted to have a directory of hundreds of audio recordings. Eachone would be a single wavelength from an interesting sound, like a bass clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end at a zero crossing so you could chain them together to make complex timbres. They could be chained in sequence, randomized, or loaded in meta-data-matched chunks. I ran into a problem figuring out how to trigger the next sound based on the ending of the last sound in a sample accurate way. Sound file loading or even buffer playback triggering waits until the start of the next block size before it updates. If you have a waveform that lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before the next waveform would start. Not only do you not get the continuous sound you want, this winds up creating a periodic pattern with a frequency of 689 Hz (44100/64).
David, I like your idea "what (if anything) someone tried to do inPd, but couldn't given its limitations". I think this could be a wonderful challenge if we could have a monthly thread like this where the best minds among us come up with solutions to some of the hardest conceptual challenges in Pd.
I'm still struggling with loading dozens of files, audio dropouts,and other similar problems. Someone else expressed frustration about Pd's single-threaded status. I too have feared upgrading my computer based on the limitations of current multicore processors (although realistically I think we can all look at the "turbo-boost" level or whatever Intel calls it to determine where our processor might run with a demanding patch. I understand the fact that you can't run your audio process on multiple cores, because it is a linear process. It would be great if the GUI could run on a second core, a process that loads audio into memory could run on third core, while GEM could automatically run on a fourth core. I don't have any concept of how feasible that would be, though. Does the GUI in pd-l2orc run on a separate core?
Sam Message: 4 Date: Tue, 23 Feb 2016 09:01:06 -0800 From: david medine < <dmedine@ucsd.edu>dmedine@ucsd.edu <javascript:_e(%7B%7D,'cvml',' dmedine@ucsd.edudmedine@ucsd.edu');>>
One thing I'd be interested in knowing about is what (ifanything) someone tried to do in Pd, but couldn't given its limitations (apart from look/feel/convenience issues).
--
*www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk < http://peimankhosravi.co.uk/miscposts.rss%3E< http://spectralkimia.wordpress.com/ http://spectralkimia.wordpress.com/%3E*
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
The issue with blocking is that you don't have fine-grained control of an audio, process, right? If you want that level of fine-grained control, you either need to explicitly set the blocksize to 1 in your patch/sub-patch, or you need to actually dig into the C code for the externals and change the logic there (which requires you write C code, recompile things, restart Pd...).
Theoretically, there could be a way to swap out the code for an external while Pd is running, rather than restarting Pd. Still, you'd have to write C and pray that you didn't introduce some terrible bug.
But theoretically, instead of writing externals in C, couldn't we come up with a high-level representation of a Pd external in a visual programming environment similar to Pd? Then we could compile that down to an external, and actually use it in our Pd patch, without actually reloading Pd. It sounds very difficult, but I imagine gen~ does something like that.
For reference, I believe Extempore provides the ability to edit and replace a low-level audio process while the program is running (I'll have to rewatch some conference videos to confirm that).
On Wed, Feb 24, 2016 at 3:41 PM, Matt Barber brbrofsvl@gmail.com wrote:
OK, now I'm having trouble even imagining how an unblocked audio model could possibly behave (at least, as David points out, in a real-time context).
On Wed, Feb 24, 2016 at 2:58 PM, David Medine dmedine@ucsd.edu wrote:
This doesn't answer Matt's question at all (apologies), but just as a clarification, ChucK *does *block audio. It's just that ChucK always blocks at the minimum size of 1 sample per block. 1 is still a block size though, and it still implies the same problems associated with order of operations, feedback, interpolating control input, and parallelization that a block size of 64 does.
Also, maybe this has already been pointed out on this thread, but block 1 is super slow because it means that you have to load all your DSP functions onto the CPU cache every 1/SR seconds instead of 64/SR seconds. Blocking by 64 buys a lot. Having a locally adjustable block size is a great feature (that ChucK lacks) because you can do it for special needs cases (like variable delay patches, for example).
Anyway, in my opinion, the block thing isn't a limit to Pd, but a limit to real-time digital signal processing.
On 2/24/2016 11:27 AM, Matt Barber wrote:
Are there any other DSP environments besides ChucK that don't block audio? Last time I tried ChucK (2012?) its efficiency was still abysmal. [block~ 1] definitely takes a hit, but it's usually possible to minimize how much of the DSP chain is actually blocked at 1. I guess with Csound you can specify a k-rate equal to the sample rate which is also effectively a single sample block. I haven't ever used Csound in a real-time context, and most of what I do with it compiles much more slowly than real time in any case.
On Wed, Feb 24, 2016 at 1:44 PM, peiman khosravi < peimankhosravi@gmail.com> wrote:
You can do this with MSP's poly~ too but I'm guessing that the CPU costs are quite heavy. Moreover, there are operators in gen that are designed for low-level operations.
*www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk *
On 24 February 2016 at 16:15, cyrille henry < ch@chnry.netch@chnry.net
wrote:
Le 24/02/2016 16:50, peiman khosravi a écrit :
One great advantage of maxmsp is gen, which gives you sample-level patching with the possibility of a one-sample delay.
you can use [block~ 1 1 1] in a pd subpatch.
cheers c
P
On Tuesday, February 23, 2016, Samuel Burt < composer.samuel.burt@gmail.com mailto:composer.samuel.burt@gmail.com> wrote:
David, One thing I attempted and couldn't find a solution for was thefollowing, mostly owing to the limitation of interfacing with a 64 sample block size.
I wanted to have a directory of hundreds of audio recordings. Eachone would be a single wavelength from an interesting sound, like a bass clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end at a zero crossing so you could chain them together to make complex timbres. They could be chained in sequence, randomized, or loaded in meta-data-matched chunks. I ran into a problem figuring out how to trigger the next sound based on the ending of the last sound in a sample accurate way. Sound file loading or even buffer playback triggering waits until the start of the next block size before it updates. If you have a waveform that lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before the next waveform would start. Not only do you not get the continuous sound you want, this winds up creating a periodic pattern with a frequency of 689 Hz (44100/64).
David, I like your idea "what (if anything) someone tried to do inPd, but couldn't given its limitations". I think this could be a wonderful challenge if we could have a monthly thread like this where the best minds among us come up with solutions to some of the hardest conceptual challenges in Pd.
I'm still struggling with loading dozens of files, audio dropouts,and other similar problems. Someone else expressed frustration about Pd's single-threaded status. I too have feared upgrading my computer based on the limitations of current multicore processors (although realistically I think we can all look at the "turbo-boost" level or whatever Intel calls it to determine where our processor might run with a demanding patch. I understand the fact that you can't run your audio process on multiple cores, because it is a linear process. It would be great if the GUI could run on a second core, a process that loads audio into memory could run on third core, while GEM could automatically run on a fourth core. I don't have any concept of how feasible that would be, though. Does the GUI in pd-l2orc run on a separate core?
Sam Message: 4 Date: Tue, 23 Feb 2016 09:01:06 -0800 From: david medine < <dmedine@ucsd.edu>dmedine@ucsd.edu <javascript:_e(%7B%7D,'cvml',' dmedine@ucsd.edudmedine@ucsd.edu');>>
One thing I'd be interested in knowing about is what (ifanything) someone tried to do in Pd, but couldn't given its limitations (apart from look/feel/convenience issues).
--
*www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk < http://peimankhosravi.co.uk/miscposts.rss%3E< http://spectralkimia.wordpress.com/ http://spectralkimia.wordpress.com/%3E*
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
How fine-grained does it need to be? As long as all the parameters are known at the beginning of the block, you have everything you need. As far as human interaction is concerned, 64-sample blocks are extremely fine-grained. The individual cycles of the pitches at the beginning of Beethoven's 5th are coarser grained. For computer generated events, there are ways to schedule events to begin in the middle of a block.
The idea of a kind of Pd JIT compiler is interesting, though.
On Wed, Feb 24, 2016 at 4:54 PM, Brian Fay ovaltinevortex@gmail.com wrote:
The issue with blocking is that you don't have fine-grained control of an audio, process, right? If you want that level of fine-grained control, you either need to explicitly set the blocksize to 1 in your patch/sub-patch, or you need to actually dig into the C code for the externals and change the logic there (which requires you write C code, recompile things, restart Pd...).
Theoretically, there could be a way to swap out the code for an external while Pd is running, rather than restarting Pd. Still, you'd have to write C and pray that you didn't introduce some terrible bug.
But theoretically, instead of writing externals in C, couldn't we come up with a high-level representation of a Pd external in a visual programming environment similar to Pd? Then we could compile that down to an external, and actually use it in our Pd patch, without actually reloading Pd. It sounds very difficult, but I imagine gen~ does something like that.
For reference, I believe Extempore provides the ability to edit and replace a low-level audio process while the program is running (I'll have to rewatch some conference videos to confirm that).
On Wed, Feb 24, 2016 at 3:41 PM, Matt Barber brbrofsvl@gmail.com wrote:
OK, now I'm having trouble even imagining how an unblocked audio model could possibly behave (at least, as David points out, in a real-time context).
On Wed, Feb 24, 2016 at 2:58 PM, David Medine dmedine@ucsd.edu wrote:
This doesn't answer Matt's question at all (apologies), but just as a clarification, ChucK *does *block audio. It's just that ChucK always blocks at the minimum size of 1 sample per block. 1 is still a block size though, and it still implies the same problems associated with order of operations, feedback, interpolating control input, and parallelization that a block size of 64 does.
Also, maybe this has already been pointed out on this thread, but block 1 is super slow because it means that you have to load all your DSP functions onto the CPU cache every 1/SR seconds instead of 64/SR seconds. Blocking by 64 buys a lot. Having a locally adjustable block size is a great feature (that ChucK lacks) because you can do it for special needs cases (like variable delay patches, for example).
Anyway, in my opinion, the block thing isn't a limit to Pd, but a limit to real-time digital signal processing.
On 2/24/2016 11:27 AM, Matt Barber wrote:
Are there any other DSP environments besides ChucK that don't block audio? Last time I tried ChucK (2012?) its efficiency was still abysmal. [block~ 1] definitely takes a hit, but it's usually possible to minimize how much of the DSP chain is actually blocked at 1. I guess with Csound you can specify a k-rate equal to the sample rate which is also effectively a single sample block. I haven't ever used Csound in a real-time context, and most of what I do with it compiles much more slowly than real time in any case.
On Wed, Feb 24, 2016 at 1:44 PM, peiman khosravi < peimankhosravi@gmail.com> wrote:
You can do this with MSP's poly~ too but I'm guessing that the CPU costs are quite heavy. Moreover, there are operators in gen that are designed for low-level operations.
*www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk *
On 24 February 2016 at 16:15, cyrille henry < ch@chnry.net ch@chnry.net> wrote:
Le 24/02/2016 16:50, peiman khosravi a écrit :
One great advantage of maxmsp is gen, which gives you sample-level patching with the possibility of a one-sample delay.
you can use [block~ 1 1 1] in a pd subpatch.
cheers c
P
On Tuesday, February 23, 2016, Samuel Burt < composer.samuel.burt@gmail.com mailto:composer.samuel.burt@gmail.com> wrote:
David, One thing I attempted and couldn't find a solution for was thefollowing, mostly owing to the limitation of interfacing with a 64 sample block size.
I wanted to have a directory of hundreds of audio recordings.Each one would be a single wavelength from an interesting sound, like a bass clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end at a zero crossing so you could chain them together to make complex timbres. They could be chained in sequence, randomized, or loaded in meta-data-matched chunks. I ran into a problem figuring out how to trigger the next sound based on the ending of the last sound in a sample accurate way. Sound file loading or even buffer playback triggering waits until the start of the next block size before it updates. If you have a waveform that lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before the next waveform would start. Not only do you not get the continuous sound you want, this winds up creating a periodic pattern with a frequency of 689 Hz (44100/64).
David, I like your idea "what (if anything) someone tried to doin Pd, but couldn't given its limitations". I think this could be a wonderful challenge if we could have a monthly thread like this where the best minds among us come up with solutions to some of the hardest conceptual challenges in Pd.
I'm still struggling with loading dozens of files, audiodropouts, and other similar problems. Someone else expressed frustration about Pd's single-threaded status. I too have feared upgrading my computer based on the limitations of current multicore processors (although realistically I think we can all look at the "turbo-boost" level or whatever Intel calls it to determine where our processor might run with a demanding patch. I understand the fact that you can't run your audio process on multiple cores, because it is a linear process. It would be great if the GUI could run on a second core, a process that loads audio into memory could run on third core, while GEM could automatically run on a fourth core. I don't have any concept of how feasible that would be, though. Does the GUI in pd-l2orc run on a separate core?
Sam Message: 4 Date: Tue, 23 Feb 2016 09:01:06 -0800 From: david medine < <dmedine@ucsd.edu>dmedine@ucsd.edu <javascript:_e(%7B%7D,'cvml',' dmedine@ucsd.edudmedine@ucsd.edu');>>
One thing I'd be interested in knowing about is what (ifanything) someone tried to do in Pd, but couldn't given its limitations (apart from look/feel/convenience issues).
--
*www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk < http://peimankhosravi.co.uk/miscposts.rss%3E< http://spectralkimia.wordpress.com/ http://spectralkimia.wordpress.com/%3E*
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Two example I can think of. One-sample delay/feedback for filter design etc. And real-time zero-crossing detection with sample-rate precision.
On Wednesday, February 24, 2016, Matt Barber brbrofsvl@gmail.com wrote:
How fine-grained does it need to be? As long as all the parameters are known at the beginning of the block, you have everything you need. As far as human interaction is concerned, 64-sample blocks are extremely fine-grained. The individual cycles of the pitches at the beginning of Beethoven's 5th are coarser grained. For computer generated events, there are ways to schedule events to begin in the middle of a block.
The idea of a kind of Pd JIT compiler is interesting, though.
On Wed, Feb 24, 2016 at 4:54 PM, Brian Fay <ovaltinevortex@gmail.com javascript:_e(%7B%7D,'cvml','ovaltinevortex@gmail.com');> wrote:
The issue with blocking is that you don't have fine-grained control of an audio, process, right? If you want that level of fine-grained control, you either need to explicitly set the blocksize to 1 in your patch/sub-patch, or you need to actually dig into the C code for the externals and change the logic there (which requires you write C code, recompile things, restart Pd...).
Theoretically, there could be a way to swap out the code for an external while Pd is running, rather than restarting Pd. Still, you'd have to write C and pray that you didn't introduce some terrible bug.
But theoretically, instead of writing externals in C, couldn't we come up with a high-level representation of a Pd external in a visual programming environment similar to Pd? Then we could compile that down to an external, and actually use it in our Pd patch, without actually reloading Pd. It sounds very difficult, but I imagine gen~ does something like that.
For reference, I believe Extempore provides the ability to edit and replace a low-level audio process while the program is running (I'll have to rewatch some conference videos to confirm that).
On Wed, Feb 24, 2016 at 3:41 PM, Matt Barber <brbrofsvl@gmail.com javascript:_e(%7B%7D,'cvml','brbrofsvl@gmail.com');> wrote:
OK, now I'm having trouble even imagining how an unblocked audio model could possibly behave (at least, as David points out, in a real-time context).
On Wed, Feb 24, 2016 at 2:58 PM, David Medine <dmedine@ucsd.edu javascript:_e(%7B%7D,'cvml','dmedine@ucsd.edu');> wrote:
This doesn't answer Matt's question at all (apologies), but just as a clarification, ChucK *does *block audio. It's just that ChucK always blocks at the minimum size of 1 sample per block. 1 is still a block size though, and it still implies the same problems associated with order of operations, feedback, interpolating control input, and parallelization that a block size of 64 does.
Also, maybe this has already been pointed out on this thread, but block 1 is super slow because it means that you have to load all your DSP functions onto the CPU cache every 1/SR seconds instead of 64/SR seconds. Blocking by 64 buys a lot. Having a locally adjustable block size is a great feature (that ChucK lacks) because you can do it for special needs cases (like variable delay patches, for example).
Anyway, in my opinion, the block thing isn't a limit to Pd, but a limit to real-time digital signal processing.
On 2/24/2016 11:27 AM, Matt Barber wrote:
Are there any other DSP environments besides ChucK that don't block audio? Last time I tried ChucK (2012?) its efficiency was still abysmal. [block~ 1] definitely takes a hit, but it's usually possible to minimize how much of the DSP chain is actually blocked at 1. I guess with Csound you can specify a k-rate equal to the sample rate which is also effectively a single sample block. I haven't ever used Csound in a real-time context, and most of what I do with it compiles much more slowly than real time in any case.
On Wed, Feb 24, 2016 at 1:44 PM, peiman khosravi < peimankhosravi@gmail.com javascript:_e(%7B%7D,'cvml','peimankhosravi@gmail.com');> wrote:
You can do this with MSP's poly~ too but I'm guessing that the CPU costs are quite heavy. Moreover, there are operators in gen that are designed for low-level operations.
*www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk *
On 24 February 2016 at 16:15, cyrille henry < javascript:_e(%7B%7D,'cvml','ch@chnry.net');ch@chnry.net javascript:_e(%7B%7D,'cvml','ch@chnry.net');> wrote:
Le 24/02/2016 16:50, peiman khosravi a écrit :
> One great advantage of maxmsp is gen, which gives you sample-level > patching with the possibility of a one-sample delay. > > you can use [block~ 1 1 1] in a pd subpatch.
cheers c
P > > On Tuesday, February 23, 2016, Samuel Burt < > composer.samuel.burt@gmail.com > javascript:_e(%7B%7D,'cvml','composer.samuel.burt@gmail.com'); > mailto:composer.samuel.burt@gmail.com javascript:_e(%7B%7D,'cvml','composer.samuel.burt@gmail.com');>> > wrote: > > David, > > One thing I attempted and couldn't find a solution for was the > following, mostly owing to the limitation of interfacing with a 64 sample > block size. > > I wanted to have a directory of hundreds of audio recordings. > Each one would be a single wavelength from an interesting sound, like a > bass clarinet, marimba, harpsichord, tambourine, etc. Each would begin and > end at a zero crossing so you could chain them together to make complex > timbres. They could be chained in sequence, randomized, or loaded in > meta-data-matched chunks. I ran into a problem figuring out how to trigger > the next sound based on the ending of the last sound in a sample accurate > way. Sound file loading or even buffer playback triggering waits until the > start of the next block size before it updates. If you have a waveform that > lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before > the next waveform would start. Not only do you not get the continuous sound > you want, this winds up creating a periodic pattern with a frequency of 689 > Hz (44100/64). > > David, I like your idea "what (if anything) someone tried to do > in Pd, but couldn't given its limitations". I think this could be a > wonderful challenge if we could have a monthly thread like this where the > best minds among us come up with solutions to some of the hardest > conceptual challenges in Pd. > > I'm still struggling with loading dozens of files, audio > dropouts, and other similar problems. Someone else expressed frustration > about Pd's single-threaded status. I too have feared upgrading my computer > based on the limitations of current multicore processors (although > realistically I think we can all look at the "turbo-boost" level or > whatever Intel calls it to determine where our processor might run with a > demanding patch. I understand the fact that you can't run your audio > process on multiple cores, because it is a linear process. It would be > great if the GUI could run on a second core, a process that loads audio > into memory could run on third core, while GEM could automatically run on a > fourth core. I don't have any concept of how feasible that would be, > though. Does the GUI in pd-l2orc run on a separate core? > > Sam > > > > > > > Message: 4 > Date: Tue, 23 Feb 2016 09:01:06 -0800 > From: david medine < > javascript:_e(%7B%7D,'cvml','dmedine@ucsd.edu');dmedine@ucsd.edu > javascript:_e(%7B%7D,'cvml','dmedine@ucsd.edu'); < > javascript:_e(%7B%7D,'cvml',' > javascript:_e(%7B%7D,'cvml','dmedine@ucsd.edu');dmedine@ucsd.edu > javascript:_e(%7B%7D,'cvml','dmedine@ucsd.edu');');>> > > One thing I'd be interested in knowing about is what (if > anything) > someone tried to do in Pd, but couldn't given its > limitations (apart > from look/feel/convenience issues). > > > > -- > > *www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk < > http://peimankhosravi.co.uk/miscposts.rss%3E< > http://spectralkimia.wordpress.com/ > http://spectralkimia.wordpress.com/%3E* > > > > _______________________________________________ > Pd-list@lists.iem.at > javascript:_e(%7B%7D,'cvml','Pd-list@lists.iem.at'); mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > http://lists.puredata.info/listinfo/pd-list > > _______________________________________________ Pd-list@lists.iem.at javascript:_e(%7B%7D,'cvml','Pd-list@lists.iem.at'); mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at javascript:_e(%7B%7D,'cvml','Pd-list@lists.iem.at'); mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
_______________________________________________Pd-list@lists.iem.at javascript:_e(%7B%7D,'cvml','Pd-list@lists.iem.at'); mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at javascript:_e(%7B%7D,'cvml','Pd-list@lists.iem.at'); mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at javascript:_e(%7B%7D,'cvml','Pd-list@lists.iem.at'); mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
2016-02-25 6:49 GMT-03:00 peiman khosravi peimankhosravi@gmail.com:
Two example I can think of. One-sample delay/feedback for filter design etc. And real-time zero-crossing detection with sample-rate precision.
you can do that in Pd vanilla with a single object: [fexpr~]
like I said, I guess there's nothing you can do in gen~ that you can't in Pd, either as a patch or in [fexpr~]. Perhaps the selling point of gen~ is being more efficient. But hey, I was just wondering how heavier Max/MSP is altogether with the whole interface and all. I mean, you can run Pd easily on a raspberry pi 0...
But in terms of efficiency, I guess nothing beats SuperCollider.
cheers
real-time zero-crossing detection with sample-rate precision.
this is something that is super simple to implement.
it's like:
if (incomingSignal > 0 && previousIncomingSignal < 0 || incomingSignal < 0 || previousIncomingSignal > 0) return 1; else return 0;
i also don't understand why such an easy tool has never been put into vanilla pd.
You don't even need that much logic for zero crossings. They are easy to find using some simple arithmetic. See attached.
On Thu, Feb 25, 2016 at 9:39 AM, i go bananas hard.off@gmail.com wrote:
real-time zero-crossing detection with sample-rate precision.
this is something that is super simple to implement.
it's like:
if (incomingSignal > 0 && previousIncomingSignal < 0 || incomingSignal < 0 || previousIncomingSignal > 0) return 1; else return 0;
i also don't understand why such an easy tool has never been put into vanilla pd.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
2016-02-25 11:39 GMT-03:00 i go bananas hard.off@gmail.com:
real-time zero-crossing detection with sample-rate precision.
this is something that is super simple to implement. (..) i also don't understand why such an easy tool has never been put into vanilla pd.
there are so many more simpler and common things that weren't implemented in vanilla before zero crossing, but yeah, like I said, you could easily do that in [fexpr~] (that's vanilla).
also there's a zerox~ object cloned from max in cyclone, btw.
cheers
this is a trick question pd is not limited, it is the most object oriented c code you will ever see in the entire universe. with some practice you can learn how to model high level polymorphic virtual destructors.
On Thu, Feb 25, 2016 at 3:29 PM, Billy Stiltner billy.stiltner@gmail.com wrote:
this is a trick question pd is not limited, it is the most object oriented c code you will ever see in the entire universe. with some practice you can learn how to model high level polymorphic virtual destructors.
This must explain the recurring nightmares I have when I'm deep in constructing a large patch: I'll dream that I have to use Pd to stop a missile that's headed for Cleveland. It's always Cleveland.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
It's always Cleveland.
You'd probably work like the dickens and make a patch that saves Cleveland. But the next day when they attack another city you'd open up the patch and be unable to make sense of all your spaghetti. At least you could use your Cleveland-saving patch as a prototype to sell software to the DoD.
-Jonathan
On Thursday, February 25, 2016 4:14 PM, Matt Barber <brbrofsvl@gmail.com> wrote:
On Thu, Feb 25, 2016 at 3:29 PM, Billy Stiltner billy.stiltner@gmail.com wrote:
this is a trick question pd is not limited, it is the most object oriented c code you will ever see in the entire universe. with some practice you can learn how to model high level polymorphic virtual destructors.
This must explain the recurring nightmares I have when I'm deep in constructing a large patch: I'll dream that I have to use Pd to stop a missile that's headed for Cleveland. It's always Cleveland.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Spaghetti is more of a Cincinnati thing.
http://www.skylinechili.com/ways.php
On Thu, Feb 25, 2016 at 4:42 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
It's always Cleveland.
You'd probably work like the dickens and make a patch that saves Cleveland. But the next day when they attack another city you'd open up the patch and be unable to make sense of all your spaghetti.
At least you could use your Cleveland-saving patch as a prototype to sell software to the DoD.
-Jonathan
On Thursday, February 25, 2016 4:14 PM, Matt Barber brbrofsvl@gmail.com wrote:
On Thu, Feb 25, 2016 at 3:29 PM, Billy Stiltner billy.stiltner@gmail.com wrote:
this is a trick question pd is not limited, it is the most object oriented c code you will ever see in the entire universe. with some practice you can learn how to model high level polymorphic virtual destructors.
This must explain the recurring nightmares I have when I'm deep in constructing a large patch: I'll dream that I have to use Pd to stop a missile that's headed for Cleveland. It's always Cleveland.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I also feel more limited than Pd.
2016-02-25 22:14 GMT+01:00 Matt Barber brbrofsvl@gmail.com:
On Thu, Feb 25, 2016 at 3:29 PM, Billy Stiltner billy.stiltner@gmail.com wrote:
this is a trick question pd is not limited, it is the most object oriented c code you will ever see in the entire universe. with some practice you can learn how to model high level polymorphic virtual destructors.
This must explain the recurring nightmares I have when I'm deep in constructing a large patch: I'll dream that I have to use Pd to stop a missile that's headed for Cleveland. It's always Cleveland.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
For me Pd is totally outstanding, even more with the Cleveland/Cincinnati spaghetti reports.
The Gui is ok, perhaps more than ok, as it is. When you are patching you always change things, and the final visual effect is irrelevant. Also straight cables (or unsegmented) are clear to follow. This minimalism, I guess, is simpler an cheaper to maintain, that makes it even better.
Help files are ok.
It`s well documented.
Works on windows, mac, linux, etc.
Limitations are that Pd-extended is no longer updated, also that Pdvst by J.Sarlo is no longer updated. Both of these form a door in which beginners enters “Computer Music” and “dsp” with Pd.
Another feature I miss is multi-language comment object. Enabling multi-language Help files, even multi-language patch comments can be lot useful!
Em qui, 25 de fev de 2016 às 13:49, Alexandre Torres Porres < porres@gmail.com> escreveu:
2016-02-25 11:39 GMT-03:00 i go bananas hard.off@gmail.com:
real-time zero-crossing detection with sample-rate precision.
this is something that is super simple to implement. (..) i also don't understand why such an easy tool has never been put into vanilla pd.
there are so many more simpler and common things that weren't implemented in vanilla before zero crossing, but yeah, like I said, you could easily do that in [fexpr~] (that's vanilla).
also there's a zerox~ object cloned from max in cyclone, btw.
cheers _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I think multi-language patch “comments” is more difficult than multi-language “Help files”.
M-L-Help files can be done translating each help file and saving it with a name like “metro-help-ES.pd” or “metro-help-FR.pd” then telling pd to add the -ES or -XX to the english helpfile name.
This is a lot of work, but can/should be done by the community, I remember that something like this has been done in Pd-extended menus with an online infrastructure, everyone contributed with what was left to be done.
Of course this increases a lot the size of the package, there should be something like downloading only the extra language that you use and not all. Some folder somewhere.
Just a sketch. Mensaje telepatico asistido por maquinas.
From: emviveros@gmail.com Date: Fri, 26 Feb 2016 17:10:02 +0000 To: porres@gmail.com; hard.off@gmail.com CC: pd-list@lists.iem.at Subject: Re: [PD] How's Pd limited?
Another feature I miss is multi-language comment object. Enabling multi-language Help files, even multi-language patch comments can be lot useful!
My struggles with it are not really limitations of pd. It's the way I have went about modelling a polyphonic synthesizer and using the tcl controls as MVC then making the controls a part of the preset machine. Everything is available for me to break the view away from the DSP its just that there are some pretty nifty things going on with the view. For instance there are toggles that change the range of the envelope ADR controls so you can have 1s,3s, 10s, and 30s controls. This is dynamic controls. Another is a dial or knob that is quantized and the range changes depending on the number of intervals the scale has per equivalence interval or what I like to call the xTave , it is used to offset the frequency in a quantitative way in steps of the scale. It doesn't matter if the intervals are specified in cents ,JI,or an edo. The scales all end up in an frequency ratio list. So the knob is used to like the "tune" or "pitch" knob yet instead of continuous or cents adjustment it allows an offset based on the scale. There are 2 banks of oscillators and only one uses this kind of control, the other is just a regular dial that offsets by a floating point. At this point of development it was found that there were way too many controls and being attached to the presets as well as the synthesizer's realtime adjustments. So Instead of making more controls I tried to reduce the amount of controls by changing the send and receive names dynamically. I guess it works for controls that are not dynamic but gets really complicated for the controls that have their properties change at runtime. Here is a thread about it. http://forum.pdpatchrepo.info/topic/5724/dollar-signs-in-objects-and-message... Also some discussion in this list. That can be solved once the controls are broke free from the presets and DSP. Making everything FUDI friendly with super neat message boxes and routing of messages through the first inlet like that can be seen in Miller's multi pickup guitar effects monster and patch repository or MAX/MSP XFM~ will be quite the task. Those are great examples of how patching should be. Branching away from puredata? Using javascript and the web browser dynamic html to make controls for the fractal sequencer. As well as a xenharmonic sequencer, a Moments of Symmetry(Erv Wilson) matrix generator to go along with Erv's mosedo.pdf There are 2 versions of it , one without the FUDI to pd stuff https://ia601408.us.archive.org/1/items/mosedo.html/mosedo.html?p=17&g=7 , the other with and another expected soon that works with any generator. The edo MOS are finite and are the "Well Formed" set of MOS, Finally Andrew Milne figured out how to calculate the cardinalities without using continued fractions or brute force. So now it is quick to generate the non rational MOS alongside the closest approximating "Well Formed" MOS using very simple code which took forever to even comprehend on paper with pencil. Things like this are complex for me with pd Now that the algorithm is coded up in javascript a pd version would be simpler to make however , having this part of the puzzle in the browser will make it easier for a general audience to use. The new text object makes things like a database of modes easy to access in pd and also is easy enough to implement a user interface with the entire list on a webpage. In pd a simple abstraction that increments an index for sets with {p} tones , an index for the modes of sizes {s} , then the index into the modes {m} with s number of notes within scales having p tones. Example: from http://www.huygens-fokker.org/docs/modename.html 14 tone equal modes: *2 3 2 2 3 2* Quasi-equal Hexatonic *2 1 2 1 2 1 2 2 1* Gould Nonatonic *1 2 1 2 1 1 2 1 2 1* Decimal-10 *2 3 3 3 3* Godzilla-5 *2 2 1 2 1 2 1 2 1* Godzilla-9 *3 2 2 3 2 2* Hedgehog-6 *1 2 2 2 1 2 2 2* Hedgehog-8 *3 3 2 3 3* Semaphore-5 *1 2 3 2 1 2 3* Superpelog-Pelog *1 2 1 2 1 2 1 2 2* Superpelog-9
p=14, s=6, m=0*: 2 3 2 2 3 2* Quasi-equal Hexatonic m=1*: 3 2 2 3 2 2* Hedgehog-6
For this set it is not too much to cycle through the entire list but for 12 and 31 edo there are many more modes. Would probably be ok to only divide the entire list up in files with the all the modes in scales with p tones instead of splitting up the list further.
The list was easy to add user interactive <div> tags and mouseover functions that send the selected mode to the synthesizer in javascript and html.
With the text object the user interface is a little different. It's only a float atom index into the list, a canvas display for the currently selected item in the list. , and a bang to send the mode off to where it can be used vs the entire interactive scrollable list in the browser. Some of the modes are specific to other scales that are Just Intonation as well as cents rather than equal division scales. So from within pd there are abstractions that accept over FUDI a scale in cents as well as a scale in Just intonation. simply snagging the intervals from the html and inserting them into the section heading onmouseover function input is all that is needed for FUDICalization implementation. With the textobject the scale intervals are easily snaggable with [text get]. For the equal division scales an abstraction exists that only needs a message containing an equivalence interval or "xTave" and number of divisions. for Bohlen Pierce - xTave = 3 3 and divisions = 13. The text object could contain the entire message on one line EqualDivision 13 3; and the text that describes it "Bohlen Pierce Equal Divisions" on another line. This is getting simpler now, I think it's a good format for data of this type which can describe in different ways , information for the user and the machine. for the modes , since they are all modes and described in the same way the "mode part of the message neednt be in the text object. Since all the data has a descriptor and information the index could simply be the entire list in 2 line pairs. description; data; description; data;
< > next / previous item is easy
for(x=0, x<2,x++) | [t f f] {float to spigot selects , then float to text get}
[text get] {out to spigot inlets} [select 0] [spigot] [canvasrx label description( [canvas[o][<][>]]redtangled
[select 1]
[ spigot ]
[r bang( / | / | / [list]
What about dynamic visualization of data that is variable in size as well as variable element controls like a piano roll midi sequencer?
it's being implemented in tcl.
how do you do it without tcl and without data structures? Food for thought!
Is pure data's entire reason for existence to perplexingly confuse the virtual parallel patchcordianist?
The webpage interface: xensynth/burningship/pdApplet/xensynthcontrol.html https://archive.org/details/Xensynth10.01
What in the Godel Bear does this mean? "Loading the file versus loading the object
There are multiple forms for storing objects on the filesystem, including abstractions, single- and multi-object library files, etc. Then there is the representation of what objects are assigned to which symbols. These don't need to be the same thing. Each patch has its own table of which symbols are attached to which objects, and this can be separate from which objects are actually loaded into memory.
One idea for handling this is to have separate tables of symbols for which object files are loaded, versus which symbols are tied to which objects for a given patch. It seems for this to be workable, there would need to be a "loaded" table, then each patch would generate its table from the loaded table. Then if an object isn't in the loaded table, the loaded table handler would go and try to load it."
Hi Billy,
Have to admit much of that went over my limited skillset. However, the MOD stuff is composition magic.
Thanks for sharing,
Julian
On 2 March 2016 at 13:55, Billy Stiltner billy.stiltner@gmail.com wrote:
My struggles with it are not really limitations of pd. It's the way I have went about modelling a polyphonic synthesizer and using the tcl controls as MVC then making the controls a part of the preset machine. Everything is available for me to break the view away from the DSP its just that there are some pretty nifty things going on with the view. For instance there are toggles that change the range of the envelope ADR controls so you can have 1s,3s, 10s, and 30s controls. This is dynamic controls. Another is a dial or knob that is quantized and the range changes depending on the number of intervals the scale has per equivalence interval or what I like to call the xTave , it is used to offset the frequency in a quantitative way in steps of the scale. It doesn't matter if the intervals are specified in cents ,JI,or an edo. The scales all end up in an frequency ratio list. So the knob is used to like the "tune" or "pitch" knob yet instead of continuous or cents adjustment it allows an offset based on the scale. There are 2 banks of oscillators and only one uses this kind of control, the other is just a regular dial that offsets by a floating point. At this point of development it was found that there were way too many controls and being attached to the presets as well as the synthesizer's realtime adjustments. So Instead of making more controls I tried to reduce the amount of controls by changing the send and receive names dynamically. I guess it works for controls that are not dynamic but gets really complicated for the controls that have their properties change at runtime. Here is a thread about it. http://forum.pdpatchrepo.info/topic/5724/dollar-signs-in-objects-and-message... Also some discussion in this list. That can be solved once the controls are broke free from the presets and DSP. Making everything FUDI friendly with super neat message boxes and routing of messages through the first inlet like that can be seen in Miller's multi pickup guitar effects monster and patch repository or MAX/MSP XFM~ will be quite the task. Those are great examples of how patching should be. Branching away from puredata? Using javascript and the web browser dynamic html to make controls for the fractal sequencer. As well as a xenharmonic sequencer, a Moments of Symmetry(Erv Wilson) matrix generator to go along with Erv's mosedo.pdf There are 2 versions of it , one without the FUDI to pd stuff https://ia601408.us.archive.org/1/items/mosedo.html/mosedo.html?p=17&g=7 , the other with and another expected soon that works with any generator. The edo MOS are finite and are the "Well Formed" set of MOS, Finally Andrew Milne figured out how to calculate the cardinalities without using continued fractions or brute force. So now it is quick to generate the non rational MOS alongside the closest approximating "Well Formed" MOS using very simple code which took forever to even comprehend on paper with pencil. Things like this are complex for me with pd Now that the algorithm is coded up in javascript a pd version would be simpler to make however , having this part of the puzzle in the browser will make it easier for a general audience to use. The new text object makes things like a database of modes easy to access in pd and also is easy enough to implement a user interface with the entire list on a webpage. In pd a simple abstraction that increments an index for sets with {p} tones , an index for the modes of sizes {s} , then the index into the modes {m} with s number of notes within scales having p tones. Example: from http://www.huygens-fokker.org/docs/modename.html 14 tone equal modes: *2 3 2 2 3 2* Quasi-equal Hexatonic *2 1 2 1 2 1 2 2 1* Gould Nonatonic *1 2 1 2 1 1 2 1 2 1* Decimal-10 *2 3 3 3 3* Godzilla-5 *2 2 1 2 1 2 1 2 1* Godzilla-9 *3 2 2 3 2 2* Hedgehog-6 *1 2 2 2 1 2 2 2* Hedgehog-8 *3 3 2 3 3* Semaphore-5 *1 2 3 2 1 2 3* Superpelog-Pelog *1 2 1 2 1 2 1 2 2* Superpelog-9
p=14, s=6, m=0*: 2 3 2 2 3 2* Quasi-equal Hexatonic m=1*: 3 2 2 3 2 2* Hedgehog-6
For this set it is not too much to cycle through the entire list but for 12 and 31 edo there are many more modes. Would probably be ok to only divide the entire list up in files with the all the modes in scales with p tones instead of splitting up the list further.
The list was easy to add user interactive <div> tags and mouseover functions that send the selected mode to the synthesizer in javascript and html.
With the text object the user interface is a little different. It's only a float atom index into the list, a canvas display for the currently selected item in the list. , and a bang to send the mode off to where it can be used vs the entire interactive scrollable list in the browser. Some of the modes are specific to other scales that are Just Intonation as well as cents rather than equal division scales. So from within pd there are abstractions that accept over FUDI a scale in cents as well as a scale in Just intonation. simply snagging the intervals from the html and inserting them into the section heading onmouseover function input is all that is needed for FUDICalization implementation. With the textobject the scale intervals are easily snaggable with [text get]. For the equal division scales an abstraction exists that only needs a message containing an equivalence interval or "xTave" and number of divisions. for Bohlen Pierce - xTave = 3 3 and divisions = 13. The text object could contain the entire message on one line EqualDivision 13 3; and the text that describes it "Bohlen Pierce Equal Divisions" on another line. This is getting simpler now, I think it's a good format for data of this type which can describe in different ways , information for the user and the machine. for the modes , since they are all modes and described in the same way the "mode part of the message neednt be in the text object. Since all the data has a descriptor and information the index could simply be the entire list in 2 line pairs. description; data; description; data;
< > next / previous item is easy
for(x=0, x<2,x++) | [t f f] {float to spigot selects , then float to text get}
[text get] {out to spigot inlets} [select 0] [spigot] [canvasrx label description( [canvas[o][<][>]]redtangled
[select 1] [ spigot ][r bang( / | / | / [list]
What about dynamic visualization of data that is variable in size as well as variable element controls like a piano roll midi sequencer?
it's being implemented in tcl.
how do you do it without tcl and without data structures? Food for thought!
Is pure data's entire reason for existence to perplexingly confuse the virtual parallel patchcordianist?
The webpage interface: xensynth/burningship/pdApplet/xensynthcontrol.html https://archive.org/details/Xensynth10.01
What in the Godel Bear does this mean? "Loading the file versus loading the object
There are multiple forms for storing objects on the filesystem, including abstractions, single- and multi-object library files, etc. Then there is the representation of what objects are assigned to which symbols. These don't need to be the same thing. Each patch has its own table of which symbols are attached to which objects, and this can be separate from which objects are actually loaded into memory.
One idea for handling this is to have separate tables of symbols for which object files are loaded, versus which symbols are tied to which objects for a given patch. It seems for this to be workable, there would need to be a "loaded" table, then each patch would generate its table from the loaded table. Then if an object isn't in the loaded table, the loaded table handler would go and try to load it."
https://puredata.info/dev/PdNamespaces
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I see a mistake in my previous post. I used the term "Well Formed" in the wrong way.
MOS = Well Formed EDO or equal division MOS have generator and period that are coprime.
Thanks for clarification. I made a mistake too MOD = MOS dhurr
On 7 March 2016 at 14:12, Billy Stiltner billy.stiltner@gmail.com wrote:
I see a mistake in my previous post. I used the term "Well Formed" in the wrong way.
MOS = Well Formed EDO or equal division MOS have generator and period that are coprime.
On 25/02/16 22:39, i go bananas wrote:
real-time zero-crossing detection with sample-rate precision.
if (incomingSignal > 0 && previousIncomingSignal < 0 || incomingSignal < 0 || previousIncomingSignal > 0) return 1; else return 0;
fexpr~ if (($x1[0] > 0 && $x1[-1] < 0) || ($x1[0] < 0 && $x1[-1] > 0), 1, 0);
Cheers,
Chris.
Or if [fexpr~] is too expensive...
On Mon, Mar 14, 2016 at 12:00 AM, Chris McCormick chris@mccormick.cx wrote:
On 25/02/16 22:39, i go bananas wrote:
real-time zero-crossing detection with sample-rate precision.
if (incomingSignal > 0 && previousIncomingSignal < 0 || incomingSignal < 0 || previousIncomingSignal > 0) return 1; else return 0;
fexpr~ if (($x1[0] > 0 && $x1[-1] < 0) || ($x1[0] < 0 && $x1[-1] > 0), 1, 0);
Cheers,
Chris.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, Feb 25, 2016 at 4:19 PM, Alexandre Torres Porres porres@gmail.com wrote:
2016-02-25 6:49 GMT-03:00 peiman khosravi peimankhosravi@gmail.com:
Two example I can think of. One-sample delay/feedback for filter design etc. And real-time zero-crossing detection with sample-rate precision.
you can do that in Pd vanilla with a single object: [fexpr~]
Don't know if anybody already mentioned it, but someone on Pd's forum posted this http://forum.pdpatchrepo.info/topic/9859/jsusfx-jesusonic-external-for-pure-... which is an external that can use the JSFX scripting language and works per sample (as the author says in the forum post). He says that it's quite CPU intensive but he's working on it..
It sounds very difficult, but I imagine gen~ does something like that.
I don't think the payoff is big enough to justify the development, unless what gets compiled are good old signal and/or control object chains that everybody is already familiar with. That's what happened with Javascript engines. It's quite extraordinary to see what can be done in the browser be people who have no idea what V8 is doing under the hood. At the same time the people who are experts are building high-quality frameworks in a few years that would have previously taken a decade to develop. And I can play old arcade games inside my browser. Everybody wins. One the other hand, that's pretty damned complex and expensive development. Outside of trivial cases like a chain of unary op signal objects with single connections, I have no idea how one would optimize Pd patches, much less on the fly. But surely the first step is better realtime analysis tools, so we can quickly know where the bulk of the CPU time is spent.
-Jonathan
On Wednesday, February 24, 2016 6:18 PM, Brian Fay <ovaltinevortex@gmail.com> wrote:
The issue with blocking is that you don't have fine-grained control of an audio, process, right? If you want that level of fine-grained control, you either need to explicitly set the blocksize to 1 in your patch/sub-patch, or you need to actually dig into the C code for the externals and change the logic there (which requires you write C code, recompile things, restart Pd...). Theoretically, there could be a way to swap out the code for an external while Pd is running, rather than restarting Pd. Still, you'd have to write C and pray that you didn't introduce some terrible bug. But theoretically, instead of writing externals in C, couldn't we come up with a high-level representation of a Pd external in a visual programming environment similar to Pd? Then we could compile that down to an external, and actually use it in our Pd patch, without actually reloading Pd. It sounds very difficult, but I imagine gen~ does something like that.
For reference, I believe Extempore provides the ability to edit and replace a low-level audio process while the program is running (I'll have to rewatch some conference videos to confirm that). On Wed, Feb 24, 2016 at 3:41 PM, Matt Barber brbrofsvl@gmail.com wrote:
OK, now I'm having trouble even imagining how an unblocked audio model could possibly behave (at least, as David points out, in a real-time context). On Wed, Feb 24, 2016 at 2:58 PM, David Medine dmedine@ucsd.edu wrote:
This doesn't answer Matt's question at all (apologies), but just as a clarification, ChucK does block audio. It's just that ChucK always blocks at the minimum size of 1 sample per block. 1 is still a block size though, and it still implies the same problems associated with order of operations, feedback, interpolating control input, and parallelization that a block size of 64 does.
Also, maybe this has already been pointed out on this thread, but block 1 is super slow because it means that you have to load all your DSP functions onto the CPU cache every 1/SR seconds instead of 64/SR seconds. Blocking by 64 buys a lot. Having a locally adjustable block size is a great feature (that ChucK lacks) because you can do it for special needs cases (like variable delay patches, for example).
Anyway, in my opinion, the block thing isn't a limit to Pd, but a limit to real-time digital signal processing.
On 2/24/2016 11:27 AM, Matt Barber wrote:
Are there any other DSP environments besides ChucK that don't block audio? Last time I tried ChucK (2012?) its efficiency was still abysmal. [block~ 1] definitely takes a hit, but it's usually possible to minimize how much of the DSP chain is actually blocked at 1. I guess with Csound you can specify a k-rate equal to the sample rate which is also effectively a single sample block. I haven't ever used Csound in a real-time context, and most of what I do with it compiles much more slowly than real time in any case.
On Wed, Feb 24, 2016 at 1:44 PM, peiman khosravi peimankhosravi@gmail.com wrote:
You can do this with MSP's poly~ too but I'm guessing that the CPU costs are quite heavy. Moreover, there are operators in gen that are designed for low-level operations.
www.peimankhosravi.co.uk
On 24 February 2016 at 16:15, cyrille henry ch@chnry.net wrote:
Le 24/02/2016 16:50, peiman khosravi a écrit :
One great advantage of maxmsp is gen, which gives you sample-level patching with the possibility of a one-sample delay.
you can use [block~ 1 1 1] in a pd subpatch.
cheers c
P
On Tuesday, February 23, 2016, Samuel Burt <composer.samuel.burt@gmail.com mailto:composer.samuel.burt@gmail.com> wrote:
David,
One thing I attempted and couldn't find a solution for was the following, mostly owing to the limitation of interfacing with a 64 sample block size.
I wanted to have a directory of hundreds of audio recordings. Each one would be a single wavelength from an interesting sound, like a bass clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end at a zero crossing so you could chain them together to make complex timbres. They could be chained in sequence, randomized, or loaded in meta-data-matched chunks. I ran into a problem figuring out how to trigger the next sound based on the ending of the last sound in a sample accurate way. Sound file loading or even buffer playback triggering waits until the start of the next block size before it updates. If you have a waveform that lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before the next waveform would start. Not only do you not get the continuous sound you want, this winds up creating a periodic pattern with a frequency of 689 Hz (44100/64).
David, I like your idea "what (if anything) someone tried to do in Pd, but couldn't given its limitations". I think this could be a wonderful challenge if we could have a monthly thread like this where the best minds among us come up with solutions to some of the hardest conceptual challenges in Pd.
I'm still struggling with loading dozens of files, audio dropouts, and other similar problems. Someone else expressed frustration about Pd's single-threaded status. I too have feared upgrading my computer based on the limitations of current multicore processors (although realistically I think we can all look at the "turbo-boost" level or whatever Intel calls it to determine where our processor might run with a demanding patch. I understand the fact that you can't run your audio process on multiple cores, because it is a linear process. It would be great if the GUI could run on a second core, a process that loads audio into memory could run on third core, while GEM could automatically run on a fourth core. I don't have any concept of how feasible that would be, though. Does the GUI in pd-l2orc run on a separate core?
Sam
Message: 4 Date: Tue, 23 Feb 2016 09:01:06 -0800 From: david medine <dmedine@ucsd.edu javascript:_e(%7B%7D,'cvml','dmedine@ucsd.edu');>
One thing I'd be interested in knowing about is what (if anything) someone tried to do in Pd, but couldn't given its limitations (apart from look/feel/convenience issues).
--
*www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk http://peimankhosravi.co.uk/miscposts.rsshttp://spectralkimia.wordpress.com/*
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
how about the "tanhauser" (heavy audio tools now) compiler, that can compile patches to C code, and then, on another step on this chain, we could make it an external?
looks like a window into a gen~ like idea, but I might be far off
cheers
2016-02-24 21:59 GMT-03:00 Jonathan Wilkes via Pd-list <pd-list@lists.iem.at
:
It sounds very difficult, but I imagine gen~ does something like that.
I don't think the payoff is big enough to justify the development, unless what gets compiled are good old signal and/or control object chains that everybody is already familiar with.
That's what happened with Javascript engines. It's quite extraordinary to see what can be done in the browser be people who have no idea what V8 is doing under the hood. At the same time the people who are experts are building high-quality frameworks in a few years that would have previously taken a decade to develop. And I can play old arcade games inside my browser. Everybody wins.
One the other hand, that's pretty damned complex and expensive development. Outside of trivial cases like a chain of unary op signal objects with single connections, I have no idea how one would optimize Pd patches, much less on the fly. But surely the first step is better realtime analysis tools, so we can quickly know where the bulk of the CPU time is spent.
-Jonathan
On Wednesday, February 24, 2016 6:18 PM, Brian Fay < ovaltinevortex@gmail.com> wrote:
The issue with blocking is that you don't have fine-grained control of an audio, process, right? If you want that level of fine-grained control, you either need to explicitly set the blocksize to 1 in your patch/sub-patch, or you need to actually dig into the C code for the externals and change the logic there (which requires you write C code, recompile things, restart Pd...).
Theoretically, there could be a way to swap out the code for an external while Pd is running, rather than restarting Pd. Still, you'd have to write C and pray that you didn't introduce some terrible bug.
But theoretically, instead of writing externals in C, couldn't we come up with a high-level representation of a Pd external in a visual programming environment similar to Pd? Then we could compile that down to an external, and actually use it in our Pd patch, without actually reloading Pd. It sounds very difficult, but I imagine gen~ does something like that.
For reference, I believe Extempore provides the ability to edit and replace a low-level audio process while the program is running (I'll have to rewatch some conference videos to confirm that).
On Wed, Feb 24, 2016 at 3:41 PM, Matt Barber brbrofsvl@gmail.com wrote:
OK, now I'm having trouble even imagining how an unblocked audio model could possibly behave (at least, as David points out, in a real-time context).
On Wed, Feb 24, 2016 at 2:58 PM, David Medine dmedine@ucsd.edu wrote:
This doesn't answer Matt's question at all (apologies), but just as a clarification, ChucK *does *block audio. It's just that ChucK always blocks at the minimum size of 1 sample per block. 1 is still a block size though, and it still implies the same problems associated with order of operations, feedback, interpolating control input, and parallelization that a block size of 64 does.
Also, maybe this has already been pointed out on this thread, but block 1 is super slow because it means that you have to load all your DSP functions onto the CPU cache every 1/SR seconds instead of 64/SR seconds. Blocking by 64 buys a lot. Having a locally adjustable block size is a great feature (that ChucK lacks) because you can do it for special needs cases (like variable delay patches, for example).
Anyway, in my opinion, the block thing isn't a limit to Pd, but a limit to real-time digital signal processing.
On 2/24/2016 11:27 AM, Matt Barber wrote:
Are there any other DSP environments besides ChucK that don't block audio? Last time I tried ChucK (2012?) its efficiency was still abysmal. [block~ 1] definitely takes a hit, but it's usually possible to minimize how much of the DSP chain is actually blocked at 1. I guess with Csound you can specify a k-rate equal to the sample rate which is also effectively a single sample block. I haven't ever used Csound in a real-time context, and most of what I do with it compiles much more slowly than real time in any case.
On Wed, Feb 24, 2016 at 1:44 PM, peiman khosravi <peimankhosravi@gmail.com
wrote:
You can do this with MSP's poly~ too but I'm guessing that the CPU costs are quite heavy. Moreover, there are operators in gen that are designed for low-level operations.
*www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk/ *
On 24 February 2016 at 16:15, cyrille henry < ch@chnry.netch@chnry.net> wrote:
Le 24/02/2016 16:50, peiman khosravi a écrit :
One great advantage of maxmsp is gen, which gives you sample-level patching with the possibility of a one-sample delay.
you can use [block~ 1 1 1] in a pd subpatch.
cheers c
P
On Tuesday, February 23, 2016, Samuel Burt <composer.samuel.burt@gmail.com mailto:composer.samuel.burt@gmail.com> wrote:
David, One thing I attempted and couldn't find a solution for was thefollowing, mostly owing to the limitation of interfacing with a 64 sample block size.
I wanted to have a directory of hundreds of audio recordings. Each onewould be a single wavelength from an interesting sound, like a bass clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end at a zero crossing so you could chain them together to make complex timbres. They could be chained in sequence, randomized, or loaded in meta-data-matched chunks. I ran into a problem figuring out how to trigger the next sound based on the ending of the last sound in a sample accurate way. Sound file loading or even buffer playback triggering waits until the start of the next block size before it updates. If you have a waveform that lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before the next waveform would start. Not only do you not get the continuous sound you want, this winds up creating a periodic pattern with a frequency of 689 Hz (44100/64).
David, I like your idea "what (if anything) someone tried to do in Pd,but couldn't given its limitations". I think this could be a wonderful challenge if we could have a monthly thread like this where the best minds among us come up with solutions to some of the hardest conceptual challenges in Pd.
I'm still struggling with loading dozens of files, audio dropouts, andother similar problems. Someone else expressed frustration about Pd's single-threaded status. I too have feared upgrading my computer based on the limitations of current multicore processors (although realistically I think we can all look at the "turbo-boost" level or whatever Intel calls it to determine where our processor might run with a demanding patch. I understand the fact that you can't run your audio process on multiple cores, because it is a linear process. It would be great if the GUI could run on a second core, a process that loads audio into memory could run on third core, while GEM could automatically run on a fourth core. I don't have any concept of how feasible that would be, though. Does the GUI in pd-l2orc run on a separate core?
Sam Message: 4 Date: Tue, 23 Feb 2016 09:01:06 -0800 From: david medine < <dmedine@ucsd.edu>dmedine@ucsd.edu <javascript:_e(%7B%7D,'cvml',' dmedine@ucsd.edudmedine@ucsd.edu');>>
One thing I'd be interested in knowing about is what (if anything) someone tried to do in Pd, but couldn't given its limitations(apart from look/feel/convenience issues).
--
*www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk < http://peimankhosravi.co.uk/miscposts.rss%3E< http://spectralkimia.wordpress.com/http://spectralkimia.wordpress.com/%3E*
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
2016-02-24 18:54 GMT-03:00 Brian Fay ovaltinevortex@gmail.com:
The issue with blocking is that you don't have fine-grained control of an audio, process, right?
there are plenty techniques for having patches running with sample accuracy
- problem is that most pd and max objects miss this point, supercollider
seems to be more at it. For example, you can reset the phase of osc~ or phasor~ via control messages only, if you could trigger it via an impulse oscillator, you could easy have hard synced oscillators, but no... if you want that, you need to make a more complicated patch, but there are ways around it.
you could easy have hard synced oscillators, but no...
yes, you can, with a little trick. See my abstraction (needs zexy).
Have fun.
Gesendet: Donnerstag, 25. Februar 2016 um 03:22 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Brian Fay" ovaltinevortex@gmail.com Cc: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] How's Pd limited?
2016-02-24 18:54 GMT-03:00 Brian Fay ovaltinevortex@gmail.com: The issue with blocking is that you don't have fine-grained control of an audio, process, right? there are plenty techniques for having patches running with sample accuracy - problem is that most pd and max objects miss this point, supercollider seems to be more at it. For example, you can reset the phase of osc~ or phasor~ via control messages only, if you could trigger it via an impulse oscillator, you could easy have hard synced oscillators, but no... if you want that, you need to make a more complicated patch, but there are ways around it._______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]
2016-02-25 12:47 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
you could easy have hard synced oscillators, but no...
yes, you can, with a little trick. See my abstraction (needs zexy).
I have a simple vanilla trick already :)
On 25/02/16 02:22, Alexandre Torres Porres wrote:
easy have hard synced oscillators
phasor~ 100 | *~ 2.666 | wrap~ | dac~
doing it bandlimited so it doesn't sound like poop is a lot harder (you can get part of the way there by oversampling with filtering)
Claude
Just poll every microsecond, and increment the counter by one microsecond. If there's something scheduled for that microsecond, do it. :)
On Wednesday, February 24, 2016 4:19 PM, Matt Barber <brbrofsvl@gmail.com> wrote:
OK, now I'm having trouble even imagining how an unblocked audio model could possibly behave (at least, as David points out, in a real-time context). On Wed, Feb 24, 2016 at 2:58 PM, David Medine dmedine@ucsd.edu wrote:
This doesn't answer Matt's question at all (apologies), but just as a clarification, ChucK does block audio. It's just that ChucK always blocks at the minimum size of 1 sample per block. 1 is still a block size though, and it still implies the same problems associated with order of operations, feedback, interpolating control input, and parallelization that a block size of 64 does.
Also, maybe this has already been pointed out on this thread, but block 1 is super slow because it means that you have to load all your DSP functions onto the CPU cache every 1/SR seconds instead of 64/SR seconds. Blocking by 64 buys a lot. Having a locally adjustable block size is a great feature (that ChucK lacks) because you can do it for special needs cases (like variable delay patches, for example).
Anyway, in my opinion, the block thing isn't a limit to Pd, but a limit to real-time digital signal processing.
On 2/24/2016 11:27 AM, Matt Barber wrote:
Are there any other DSP environments besides ChucK that don't block audio? Last time I tried ChucK (2012?) its efficiency was still abysmal. [block~ 1] definitely takes a hit, but it's usually possible to minimize how much of the DSP chain is actually blocked at 1. I guess with Csound you can specify a k-rate equal to the sample rate which is also effectively a single sample block. I haven't ever used Csound in a real-time context, and most of what I do with it compiles much more slowly than real time in any case.
On Wed, Feb 24, 2016 at 1:44 PM, peiman khosravi peimankhosravi@gmail.com wrote:
You can do this with MSP's poly~ too but I'm guessing that the CPU costs are quite heavy. Moreover, there are operators in gen that are designed for low-level operations.
www.peimankhosravi.co.uk
On 24 February 2016 at 16:15, cyrille henry ch@chnry.net wrote:
Le 24/02/2016 16:50, peiman khosravi a écrit :
One great advantage of maxmsp is gen, which gives you sample-level patching with the possibility of a one-sample delay.
you can use [block~ 1 1 1] in a pd subpatch.
cheers c
P
On Tuesday, February 23, 2016, Samuel Burt <composer.samuel.burt@gmail.com mailto:composer.samuel.burt@gmail.com> wrote:
David,
One thing I attempted and couldn't find a solution for was the following, mostly owing to the limitation of interfacing with a 64 sample block size.
I wanted to have a directory of hundreds of audio recordings. Each one would be a single wavelength from an interesting sound, like a bass clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end at a zero crossing so you could chain them together to make complex timbres. They could be chained in sequence, randomized, or loaded in meta-data-matched chunks. I ran into a problem figuring out how to trigger the next sound based on the ending of the last sound in a sample accurate way. Sound file loading or even buffer playback triggering waits until the start of the next block size before it updates. If you have a waveform that lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before the next waveform would start. Not only do you not get the continuous sound you want, this winds up creating a periodic pattern with a frequency of 689 Hz (44100/64).
David, I like your idea "what (if anything) someone tried to do in Pd, but couldn't given its limitations". I think this could be a wonderful challenge if we could have a monthly thread like this where the best minds among us come up with solutions to some of the hardest conceptual challenges in Pd.
I'm still struggling with loading dozens of files, audio dropouts, and other similar problems. Someone else expressed frustration about Pd's single-threaded status. I too have feared upgrading my computer based on the limitations of current multicore processors (although realistically I think we can all look at the "turbo-boost" level or whatever Intel calls it to determine where our processor might run with a demanding patch. I understand the fact that you can't run your audio process on multiple cores, because it is a linear process. It would be great if the GUI could run on a second core, a process that loads audio into memory could run on third core, while GEM could automatically run on a fourth core. I don't have any concept of how feasible that would be, though. Does the GUI in pd-l2orc run on a separate core?
Sam
Message: 4 Date: Tue, 23 Feb 2016 09:01:06 -0800 From: david medine <dmedine@ucsd.edu javascript:_e(%7B%7D,'cvml','dmedine@ucsd.edu');>
One thing I'd be interested in knowing about is what (if anything) someone tried to do in Pd, but couldn't given its limitations (apart from look/feel/convenience issues).
--
*www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk http://peimankhosravi.co.uk/miscposts.rsshttp://spectralkimia.wordpress.com/*
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You can do somthing like MSP poly~ with Pd poly and switch~ or route and switch~. The (64+64+64+13) example can be corrected by knowing when its going to end, ie sheduling the next one when that one is fired, as long as its longer than 1 block (64samples). You need to store the name of the file with the file lenght. then somthing with the del object. better with alternating 2 players (readsf~, table or other). Mensaje telepatico asistido por maquinas.
Date: Wed, 24 Feb 2016 18:44:00 +0000 From: peimankhosravi@gmail.com To: ch@chnry.net CC: pd-list@lists.iem.at Subject: Re: [PD] How's Pd limited?
You can do this with MSP's poly~ too but I'm guessing that the CPU costs are quite heavy. Moreover, there are operators in gen that are designed for low-level operations.
www.peimankhosravi.co.uk
On 24 February 2016 at 16:15, cyrille henry ch@chnry.net wrote:
Le 24/02/2016 16:50, peiman khosravi a écrit :
One great advantage of maxmsp is gen, which gives you sample-level patching with the possibility of a one-sample delay.
you can use [block~ 1 1 1] in a pd subpatch.
cheers
c
P
On Tuesday, February 23, 2016, Samuel Burt <composer.samuel.burt@gmail.com mailto:composer.samuel.burt@gmail.com> wrote:
David,
One thing I attempted and couldn't find a solution for was the following, mostly owing to the limitation of interfacing with a 64 sample block size.
I wanted to have a directory of hundreds of audio recordings. Each one would be a single wavelength from an interesting sound, like a bass clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end at a zero crossing so you could chain them together to make complex timbres. They could be chained in sequence, randomized, or loaded in meta-data-matched chunks. I ran into a problem figuring out how to trigger the next sound based on the ending of the last sound in a sample accurate way. Sound file loading or even buffer playback triggering waits until the start of the next block size before it updates. If you have a waveform that lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before the next waveform would start. Not only do you not get the continuous sound you want, this winds up creating a periodic pattern with a frequency of 689 Hz (44100/64).
David, I like your idea "what (if anything) someone tried to do in Pd, but couldn't given its limitations". I think this could be a wonderful challenge if we could have a monthly thread like this where the best minds among us come up with solutions to some of the hardest conceptual challenges in Pd.
I'm still struggling with loading dozens of files, audio dropouts, and other similar problems. Someone else expressed frustration about Pd's single-threaded status. I too have feared upgrading my computer based on the limitations of current multicore processors (although realistically I think we can all look at the "turbo-boost" level or whatever Intel calls it to determine where our processor might run with a demanding patch. I understand the fact that you can't run your audio process on multiple cores, because it is a linear process. It would be great if the GUI could run on a second core, a process that loads audio into memory could run on third core, while GEM could automatically run on a fourth core. I don't have any concept of how feasible that would be, though. Does the GUI in pd-l2orc run on a separate core?
Sam
Message: 4
Date: Tue, 23 Feb 2016 09:01:06 -0800
From: david medine <dmedine@ucsd.edu <javascript:_e(%7B%7D,'cvml','dmedine@ucsd.edu');>>
One thing I'd be interested in knowing about is what (if anything)
someone tried to do in Pd, but couldn't given its limitations (apart
from look/feel/convenience issues).
--
*www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk http://peimankhosravi.co.uk/miscposts.rsshttp://spectralkimia.wordpress.com/*
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I think one of the big limitations is a difficulty in turning "hot" code "cool". For example, suppose the [hungry~] abstraction is at the heart of your patch but it consumes a lot of CPU. What do you do? Typically the process involves only two steps:1. make esoteric changes that marginally decrease the CPU load2. give up and port [hungry~] to a C or C++ external #1 decreases readability, and #2 decreases portability (and hopefully readability as well).
Parallelization may be a means to address this, but it is a means and not an end. In any case the first place to start is to profile CPU usage and patch performance, as well as signal and object performance within the patch. Pd needs tools to accurately measure which classes and abstractions are responsible when a patch runs hot.
Desiredata apparently added some functionality to do that but it was apparently buggy and didn't get a lot of testing. Anyhow, these tools are crucial to a sensible discussion of parallelization-- without them we can only measure object performance with very blunt tools. -Jonathan
On Wednesday, February 24, 2016 10:53 AM, peiman khosravi peimankhosravi@gmail.com wrote:
One great advantage of maxmsp is gen, which gives you sample-level patching with the possibility of a one-sample delay. P
On Tuesday, February 23, 2016, Samuel Burt composer.samuel.burt@gmail.com wrote:
David, One thing I attempted and couldn't find a solution for was the following, mostly owing to the limitation of interfacing with a 64 sample block size. I wanted to have a directory of hundreds of audio recordings. Each one would be a single wavelength from an interesting sound, like a bass clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end at a zero crossing so you could chain them together to make complex timbres. They could be chained in sequence, randomized, or loaded in meta-data-matched chunks. I ran into a problem figuring out how to trigger the next sound based on the ending of the last sound in a sample accurate way. Sound file loading or even buffer playback triggering waits until the start of the next block size before it updates. If you have a waveform that lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before the next waveform would start. Not only do you not get the continuous sound you want, this winds up creating a periodic pattern with a frequency of 689 Hz (44100/64). David, I like your idea "what (if anything) someone tried to do in Pd, but couldn't given its limitations". I think this could be a wonderful challenge if we could have a monthly thread like this where the best minds among us come up with solutions to some of the hardest conceptual challenges in Pd. I'm still struggling with loading dozens of files, audio dropouts, and other similar problems. Someone else expressed frustration about Pd's single-threaded status. I too have feared upgrading my computer based on the limitations of current multicore processors (although realistically I think we can all look at the "turbo-boost" level or whatever Intel calls it to determine where our processor might run with a demanding patch. I understand the fact that you can't run your audio process on multiple cores, because it is a linear process. It would be great if the GUI could run on a second core, a process that loads audio into memory could run on third core, while GEM could automatically run on a fourth core. I don't have any concept of how feasible that would be, though. Does the GUI in pd-l2orc run on a separate core? Sam
Message: 4 Date: Tue, 23 Feb 2016 09:01:06 -0800 From: david medine dmedine@ucsd.edu
One thing I'd be interested in knowing about is what (if anything) someone tried to do in Pd, but couldn't given its limitations (apart from look/feel/convenience issues).
-
Alexandre Torres Porres -
Alexandros Drymonitis -
Antoine Rousseau -
Billy Stiltner -
Brian Fay -
Chris McCormick -
Christof Ressi -
Claude Heiland-Allen -
cyrille henry -
David Medine -
Esteban Viveros -
i go bananas -
Jonathan Wilkes -
Julian Brooks -
Lucas Cordiviola -
Matt Barber -
Mikael at UL -
peiman khosravi -
Samuel Burt