[PD] How's Pd limited?

Thu Feb 25 03:27:58 CET 2016

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 at 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 at 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 at 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 at 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 at 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 at chnry.net>ch at 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 at gmail.com
> <mailto:composer.samuel.burt at 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 at ucsd.edu>dmedine at ucsd.edu <
> javascript:_e(%7B%7D,'cvml',' <dmedine at ucsd.edu>dmedine at 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/>http://spectralkimia.wordpress.com/>*
>
>
>
> _______________________________________________
> Pd-list at 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 at 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 at 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160224/2c5cf8a5/attachment-0001.html>