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@kapsi.fi To: Pd-List pd-list@lists.iem.at Subject: [PD] Does Pd have a "sound"? Message-ID: D9A862C4-2F6E-4BFB-9D7D-B48A0DEC5A82@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@metalu.net To: Pd-list pd-list@lists.iem.at Subject: Re: [PD] Nettles. Was: Cyclone: List of Issues with existing objects by Alexandre Porres Message-ID: < CAOCG5HwDcssRYAdkw9MQ1QvV-LivXDYfkVzYZaV2E1mH7znv0Q@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@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@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@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@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@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@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@gmail.com mailto:porres@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-3nXy2Q...
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@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@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@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
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@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@kapsi.fi mailto:mviljamaa@kapsi.fi> To: Pd-List <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: [PD] Does Pd have a "sound"? Message-ID: <D9A862C4-2F6E-4BFB-9D7D-B48A0DEC5A82@kapsi.fi mailto:D9A862C4-2F6E-4BFB-9D7D-B48A0DEC5A82@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@metalu.net mailto:antoine@metalu.net> To: Pd-list <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: Re: [PD] Nettles. Was: Cyclone: List of Issues with existing objects by Alexandre Porres Message-ID: <CAOCG5HwDcssRYAdkw9MQ1QvV-LivXDYfkVzYZaV2E1mH7znv0Q@mail.gmail.com mailto:CAOCG5HwDcssRYAdkw9MQ1QvV-LivXDYfkVzYZaV2E1mH7znv0Q@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@lists.iem.at mailto:pd-list@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@gmail.com mailto:brbrofsvl@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@vt.edu mailto:ico@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@vt.edu mailto:ico@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@vt.edu mailto:ico@vt.edu www.performingarts.vt.edu http://www.performingarts.vt.edu/ disis.icat.vt.edu http://disis.icat.vt.edu/ l2ork.icat.vt.edu http://l2ork.icat.vt.edu/ ico.bukvic.net http://ico.bukvic.net/ On Feb 14, 2016 8:40 AM, "Fred Jan Kraan" <fjkraan@xs4all.nl mailto:fjkraan@xs4all.nl> wrote:
Hi Alexandre,
guess some of it is in: http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/cycloneToDo.html 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@gmail.com mailto:porres@gmail.com <mailto:porres@gmail.com mailto:porres@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-3nXy2Q... 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@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> <http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> <http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailto:Pd-list@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@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
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@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@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@kapsi.fi To: Pd-List pd-list@lists.iem.at Subject: [PD] Does Pd have a "sound"? Message-ID: D9A862C4-2F6E-4BFB-9D7D-B48A0DEC5A82@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@metalu.net To: Pd-list pd-list@lists.iem.at Subject: Re: [PD] Nettles. Was: Cyclone: List of Issues with existing objects by Alexandre Porres Message-ID: < CAOCG5HwDcssRYAdkw9MQ1QvV-LivXDYfkVzYZaV2E1mH7znv0Q@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@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@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@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@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@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@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@gmail.com mailto:porres@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-3nXy2Q...
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@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@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@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
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@kapsi.fi mailto:mviljamaa@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@gmail.com <mailto:composer.samuel.burt@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@kapsi.fi <mailto:mviljamaa@kapsi.fi>> To: Pd-List <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>> Subject: [PD] Does Pd have a "sound"? Message-ID: <D9A862C4-2F6E-4BFB-9D7D-B48A0DEC5A82@kapsi.fi <mailto:D9A862C4-2F6E-4BFB-9D7D-B48A0DEC5A82@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@metalu.net <mailto:antoine@metalu.net>> To: Pd-list <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>> Subject: Re: [PD] Nettles. Was: Cyclone: List of Issues with existing objects by Alexandre Porres Message-ID: <CAOCG5HwDcssRYAdkw9MQ1QvV-LivXDYfkVzYZaV2E1mH7znv0Q@mail.gmail.com <mailto:CAOCG5HwDcssRYAdkw9MQ1QvV-LivXDYfkVzYZaV2E1mH7znv0Q@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@lists.iem.at <mailto:pd-list@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@gmail.com <mailto:brbrofsvl@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@vt.edu <mailto:ico@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@vt.edu <mailto:ico@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 <tel:%28540%29%20231-6139> > ico@vt.edu <mailto:ico@vt.edu> > www.performingarts.vt.edu <http://www.performingarts.vt.edu/> > disis.icat.vt.edu <http://disis.icat.vt.edu/> > l2ork.icat.vt.edu <http://l2ork.icat.vt.edu/> > ico.bukvic.net <http://ico.bukvic.net/> > On Feb 14, 2016 8:40 AM, "Fred Jan Kraan" <fjkraan@xs4all.nl <mailto:fjkraan@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@gmail.com <mailto:porres@gmail.com> > <mailto:porres@gmail.com <mailto:porres@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@lists.iem.at <mailto:Pd-list@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@lists.iem.at <mailto:Pd-list@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@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >
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@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@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@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@kapsi.fi To: Pd-List pd-list@lists.iem.at Subject: [PD] Does Pd have a "sound"? Message-ID: D9A862C4-2F6E-4BFB-9D7D-B48A0DEC5A82@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@metalu.net To: Pd-list pd-list@lists.iem.at Subject: Re: [PD] Nettles. Was: Cyclone: List of Issues with existing objects by Alexandre Porres Message-ID: < CAOCG5HwDcssRYAdkw9MQ1QvV-LivXDYfkVzYZaV2E1mH7znv0Q@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@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@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@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@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@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@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@gmail.com mailto:porres@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-3nXy2Q...
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@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@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@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