Re: [PD] How's Pd limited?

[peiman khosravi]

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 <brbrof...@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 <ovaltinevor...@gmail.com
> <javascript:_e(%7B%7D,'cvml','ovaltinevor...@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 <brbrof...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','brbrof...@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 <dmed...@ucsd.edu
>>> <javascript:_e(%7B%7D,'cvml','dmed...@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 <
>>>> peimankhosr...@gmail.com
>>>> <javascript:_e(%7B%7D,'cvml','peimankhosr...@gmail.com');>> wrote:
>>>>
>&

Re: [PD] How's Pd limited?

[peiman khosravi]

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 <c...@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.b...@gmail.com <mailto:composer.samuel.b...@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 <dmed...@ucsd.edu
>> <javascript:_e(%7B%7D,'cvml','dmed...@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><
>> http://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

Re: [PD] How's Pd limited?

[peiman khosravi]

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

*
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] SDIF files in Pd

[peiman khosravi]

From what I remember, sinusoids~ doesn't actually read sdif files
directly. It accepts lists of frequencies and amplitudes. You should
be able to design something like that in pure pd. (Look at the partial
analysis example patch.)

I just came across this: http://mtg.upf.edu/people/eakin?p=Pd%20Stuff
So it looks like you can read sdif files in pd.



www.peimankhosravi.co.uk || RSS Feed || Concert News


On 13 January 2015 at 14:53, Gilberto Agostinho
gilbertohasn...@googlemail.com wrote:
 Hello all,

 Does anyone here have any experience with SDIF files in Pure Data? When I
 used to patch in Max MSP, I used an object called [sinusoids~], created by
 CNMAT, which would read SDIF files and resynthesize them. I found this very
 old thread about it
 http://lists.puredata.info/pipermail/pd-list/2004-03/018592.html but I can't
 find any objects for Pure Data on CNMAT's website, only Max stuff. Does
 anyone know if it's still possible to handle SDIF files with Pd, and if yes
 then how to do it? Thanks a lot in advance.


 Best,
 Gilberto Agostinho


 ___
 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