[PD] Does Pd have a "sound"?

[Matt Barber]

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
>> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160214/87f2c449/attachment-0001.html>