[PD] Does Pd have a "sound"?

Mon Feb 15 01:23:01 CET 2016

It shouldn't matter so much if the back end supports doubles, but there are
plenty of things where processing in double precision internally would make
a lot of difference.
On Feb 14, 2016 6:48 PM, "David Medine" <dmedine at ucsd.edu> wrote:

> I've noticed a pretty substantial "quality" difference between using
> floats and doubles for certain things as well. I'm not sure how this all
> shakes down, since it depends not only on the programming environment, but
> also the audio API (e.g. portaudio --last time I looked at it -- doesn't
> support double precision floating point values...)
>
> On 02/14/2016 03:23 PM, Matt Barber wrote:
>
> What's really needed is blind A/B tests of "the same" or very similar
> sounds made in each.
>
> A couple of notes: SC's cubic interpolator is different from Pd's (which
> is the same as csound's). Pd's [osc~] probably ought to be replaced with
> [tabosc4~] for some things.
>
> On Sun, Feb 14, 2016 at 6:14 PM, Matti Viljamaa <mviljamaa at kapsi.fi>
> wrote:
>
>> At the very least it could be interesting to figure out what’s causing
>> the “lesser quality” sound perception.
>>
>> Then perhaps make a .pd patch containing “high quality implementations”.
>>
>> I’m not talking about effects, but more like the “basics” such as
>> oscillators and whether they’re somehow fixed to sound “Pd”, or whether
>> it’s possible to model better (or any kind of) sounds in Pd.
>>
>> -Matti
>>
>> On 15 Feb 2016, at 01:09, Samuel Burt <composer.samuel.burt at gmail.com>
>> wrote:
>>
>> If anything Pd's sound would be related to its 64 sample block size that
>> is mostly evident when people don't use sample rate line~ objects to smooth
>> their signals.
>>
>> I'd say many other audio environments provide easy tools for dynamics
>> management, reverberation, and EQ. This creates a particular sound for
>> those environments. The fact that you have to build these from scratch in
>> Pd causes me to assume that the easiest to build routines for these
>> purposes would influence the sound of neophyte patches, but as people
>> develope more sophisticated and original processes, there would be a
>> significant diverging of sonic characteristics between patches.
>>
>> One final thing that might influence the "sound" of Pd or Max is the use
>> of whole numbers to represent frequencies and time values that are
>> determined in milliseconds. This might make a lot of patches sound like
>> they are based on the harmonic spectrum of 1Hz.
>>
>> TLDR: If you want a more sophisticated sound, use line~ objects to smooth
>> signal rate control of audio processes, build your own dynamics management,
>> reverberation, and filter told, and make sure to use a variety of floating
>> point numbers or other special ratios to determine frequencies and
>> durations. At this point, I don't think people could tell your sound came
>> from Pd.
>>
>>
>>>
>>>
>>> Message: 3
>>> Date: Mon, 15 Feb 2016 00:27:08 +0200
>>> From: Matti Viljamaa <mviljamaa at kapsi.fi>
>>> To: Pd-List <pd-list at lists.iem.at>
>>> Subject: [PD] Does Pd have a "sound"?
>>> Message-ID: <D9A862C4-2F6E-4BFB-9D7D-B48A0DEC5A82 at kapsi.fi>
>>> Content-Type: text/plain; charset=utf-8
>>>
>>> Do you think Pd has a characteristic sound to it? Or whether discussion
>>> board threads claiming Pd (and Max) have a distinct (and not good) sound
>>> just have people who haven’t listened to good patches?
>>>
>>> -Matti
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 4
>>> Date: Sun, 14 Feb 2016 23:32:18 +0100
>>> From: Antoine Rousseau <antoine at metalu.net>
>>> To: Pd-list <pd-list at lists.iem.at>
>>> Subject: Re: [PD] Nettles. Was: Cyclone: List of Issues with existing
>>>         objects by Alexandre Porres
>>> Message-ID:
>>>         <
>>> CAOCG5HwDcssRYAdkw9MQ1QvV-LivXDYfkVzYZaV2E1mH7znv0Q at mail.gmail.com>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> I've only partially followed all this discussion (not using Max myself),
>>> but maybe an object I wrote could help you building such abstractions :
>>>
>>> [moonlib/dinlet~] is an [inlet~] with an init float value (constant
>>> signal)
>>> as an argument.
>>> This default value is overloaded when a signal is connected to the inlet,
>>> but restored when the signal is disconnected. A float sent to it would
>>> overwrite the default constant value.
>>>
>>> Of course the init default value could be one of the abstraction's
>>> arguments ($xxx)...
>>>
>>> BUT :
>>>
>>> - there is a very little hack (which could be called a bugfix...) that
>>> has
>>> to be made to pd source (this change is written in comment in the source
>>> file of dinlet~). I should open a ticket for that in the sourceforge
>>> repo.
>>> The involved bug is mixing the different float values up when [dinlet~]
>>> is
>>> used together with normal [inlet]s.
>>>
>>> - I should add a missing feature in dinlet~, which would add an inlet to
>>> the [dinlet~] object itself, to allow changing the default value inside
>>> of
>>> the abstraction.
>>>
>>> If anyone think this would be helpful, I could do this (open a ticket and
>>> update moonlib about this missing inlet).
>>>
>>>
>>>
>>> 2016-02-14 20:29 GMT+01:00 Jonathan Wilkes via Pd-list <
>>> pd-list at lists.iem.at
>>> >:
>>>
>>> > > Why not simply have an inlet that can handle both inside an
>>> abstraction
>>> > and route signal one way and number the other and then sprinkle that
>>> with
>>> > dynamic nlet creation and you're done? Then you can simply abstract
>>> most
>>> > cases.
>>> >
>>> > I read (and like) your spec on dynamic nlet creation, but I have a
>>> problem
>>> > with section 2.1 Signals:
>>> >
>>> > "To handle the dynamic creation of signal inlets and their routing
>>> within
>>> > the abstraction, the implementation must"
>>> >
>>> > It looks like the rest of the section is missing. :)
>>> >
>>> > -Jonathan
>>> >
>>> >
>>> >
>>> >
>>> > On Sunday, February 14, 2016 1:51 PM, Matt Barber <brbrofsvl at gmail.com
>>> >
>>> > wrote:
>>> >
>>> >
>>> > I tried coding that once, but it seemed like it needed some big
>>> change in
>>> > architecture. Technically it's only the main signal that accepts both
>>> > messages and signals in this way, where you would want to route the
>>> > message. Floats should almost always be promoted to signals.
>>> >
>>> > On Sun, Feb 14, 2016 at 1:18 PM, Ivica Ico Bukvic <ico at vt.edu> wrote:
>>> >
>>> > Why not simply have an inlet that can handle both inside an abstraction
>>> > and route signal one way and number the other and then sprinkle that
>>> with
>>> > dynamic nlet creation and you're done? Then you can simply abstract
>>> most
>>> > cases.
>>> >
>>> >
>>> > On 2/14/2016 11:36 AM, Matt Barber wrote:
>>> >
>>> > [gt~] is a great example of something that could work as an
>>> abstraction,
>>> > except for the pesky right inlet which should take a signal if there's
>>> no
>>> > creation argument, but float otherwise.
>>> >
>>> > On Sun, Feb 14, 2016 at 10:50 AM, Ivica Bukvic <ico at vt.edu> wrote:
>>> >
>>> > What I am also trying to do eventually in pd-l2ork is weed out
>>> redundant
>>> > objects and only keep the ones that do the said task the best while
>>> still
>>> > supporting other objects' idiosyncrasies (if any). There is absolutely
>>> no
>>> > reason to have multiple objects of the same kind. Ultimately, one could
>>> > keep all the externals in the same folder and completely do away with
>>> all
>>> > the declares, imports, and other things that make learning pd
>>> unnecessarily
>>> > harder.
>>> > --
>>> > Ivica Ico Bukvic, D.M.A.
>>> > Associate Professor
>>> > Computer Music
>>> > ICAT Senior Fellow
>>> > Director -- DISIS, L2Ork
>>> > Virginia Tech
>>> > School of Performing Arts – 0141
>>> > Blacksburg, VA 24061
>>> > (540) 231-6139 <%28540%29%20231-6139>
>>> > ico at vt.edu
>>> > www.performingarts.vt.edu
>>> > disis.icat.vt.edu
>>> > l2ork.icat.vt.edu
>>> > ico.bukvic.net
>>> > On Feb 14, 2016 8:40 AM, "Fred Jan Kraan" <fjkraan at xs4all.nl> wrote:
>>> >
>>> > Hi Alexandre,
>>> >
>>> > guess some of it is in:
>>> > http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/cycloneToDo.html
>>> >
>>> >
>>> > This list is also becoming a list of what has been done.
>>> >
>>> >
>>> > As with _nettles_
>>> >
>>> > "try to resurrect as independent object library"
>>> >
>>> > Anyway, tell me if this gets includes on this file.
>>> >
>>> >
>>> > Yes, the nettles-objects are part of the latest cyclone versions. They
>>> are
>>> > part of the nettles library, which can be loaded with [declare]. Not
>>> all
>>> > operating systems like the '<' and '>' in the object names and there is
>>> > overlap with other library objects, so only loading them when needed is
>>> > cleaner.
>>> >
>>> >
>>> > cheers
>>> >
>>> > ps. count me in for help with the help files
>>> >
>>> >
>>> > Great!
>>> >
>>> > Greetings,
>>> >
>>> > Fred Jan
>>> >
>>> >
>>> > 2016-02-11 22:18 GMT-02:00 Alexandre Torres Porres <porres at gmail.com
>>> > <mailto:porres at gmail.com>>:
>>> >
>>> >     Howdy, it's a known fact brazilians will start the year only after
>>> >     carnival, so here I am.
>>> >
>>> >     I'd like to share my list of things to do with existing Cyclone
>>> >     Objetcs. Obviously there might be other issues with other objects
>>> >     that would make them up to date with the current version of Max
>>> (Max
>>> >     7). Nonetheless, this is what I find relevant, and I've been really
>>> >     checking it through.
>>> >
>>> >     It's only about 11 objects, some has already been discussed here
>>> and
>>> >     might have been fixed or in the process to be taken care of,
>>> forgive
>>> >     me if so.
>>> >
>>> >     I have it attached and also as a link to a google doc
>>> >
>>> >
>>> >
>>> https://docs.google.com/document/d/1L_dUNgznfhaZHPKMJ3jJ_p9uIXRVP6Rs9-3nXy2Qlk8/edit?usp=sharing
>>> >
>>> >     Next, I will get together a list of new objects I think should be
>>> >     included, many of which I've already made as abstractions (kind of
>>> >     to show how it works like I did with [teeth~], cause I really think
>>> >     they should all be done as externals).
>>> >
>>> >     Cheers
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > 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
>>> >
>>> >
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL: <
>>> http://lists.puredata.info/pipermail/pd-list/attachments/20160214/68d50002/attachment.html
>>> >
>>>
>>> ------------------------------
>>>
>>> Subject: Digest Footer
>>>
>>> _______________________________________________
>>> Pd-list mailing list
>>> Pd-list at lists.iem.at
>>> to manage your subscription (including un-subscription) see
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>>
>>> ------------------------------
>>>
>>> End of Pd-list Digest, Vol 131, Issue 45
>>> ****************************************
>>>
>>
>>
>> _______________________________________________
>> 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/20160214/1179b8f0/attachment-0001.html>