[PD] How's Pd limited?

Thu Feb 25 03:19:53 CET 2016

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 at 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 at 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 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>
>>> <http://peimankhosravi.co.uk/miscposts.rss>
>>> <http://spectralkimia.wordpress.com/>*
>>>
>>> On 24 February 2016 at 16:15, cyrille henry <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
>>>>> <javascript:_e(%7B%7D,'cvml','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/>*
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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/b36a69f8/attachment.html>