Re: [PD] Does Pd have a "sound"?

[Billy Stiltner]

re: I-go-bananas said
"The filters are also very rudimentary (although, the new bob~ one looks
more promising).  Of course it is possible to write your own with the
filter primitives, but it's hard work."

bob~ is great, you do know about the 2nd outlet to vcf~  don't you?
I find myself time and time again choosing vcf~ to get a certain sound over
bob~
and my own ~fexpr cookbook filters.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Does Pd have a "sound"?

[Lorenzo Sutton]

On 16/02/2016 16:33, i go bananas wrote:
...



But on the flip side, pd's community of users is probably the single
most awesome single group of people i have ever had the fortune of being
a part of.


+1


And the limitations of not having a huge library of readymade techno
tools, is actually a real blessing.  In many ways, pd inspires out of
the box thinking.


+1

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Does Pd have a "sound"?

[cyrille henry]

Le 17/02/2016 09:15, Matt Barber a écrit :

They won't sound bad, necessarily; they just won't sound band limited. 
(Everything has its place.)

I think you just found the definitive answer on the question "does XXX sound better 
than YYY" : nothing sound bad, everything has it's place.

the answer to Matti original question is then:  board threads claiming Pd (and 
Max) have a distinct (and not good) sound just have people who haven’t listened 
to good patches.




The other reaction I expected from my question was that pd vanilla have no BL 
oscillator, but lot's of abstractions are available. So which one to test?
The point here is that pd does not have sound, but all object does. (and back 
to previous ccl about good / bad patch)



One more thing :
As soon as someone provide a test that show that SC BL oscillator sound better 
than any pd BL oscillator, i will port SC BL algorithm to a pd external.
(and back to previous point and ccl)



and finally :
ok, sorry, i'll stop trolling that thread.

cheers
c



On Feb 16, 2016 1:29 PM, "cyrille henry" <c...@chnry.net 
<mailto:c...@chnry.net>> wrote:

if you want to compare the "sound" of SC and pd, please use band limited 
operator, or both will sound bad.

cheers
c


Le 16/02/2016 19:16, Matt Barber a écrit :

Sure, send 'em along. It's good for learning. I've heard so many times that 
"SC3 just sounds better," and I'm a skeptic overall. I have a few comparisons 
of my own to try soon.

On Tue, Feb 16, 2016 at 12:53 PM, Alexandre Torres Porres <por...@gmail.com 
<mailto:por...@gmail.com> <mailto:por...@gmail.com <mailto:por...@gmail.com>>> 
wrote:

 Cool, but you see, I suspected SuperCollider would do things such 
as clip the phase from  phase 0.001 to 0.999 to prevent a harsh sawtooth, and 
also fade in (ramp) one block when a Synth starts.

 I feel it has many such details to make it sound "smoother" and 
nicer, it also seems to be a little quieter

 well, I kind like this, if I have other patches to compare, would 
you like to check? :)

 cheers

 2016-02-16 14:53 GMT-02:00 Matt Barber <brbrof...@gmail.com 
<mailto:brbrof...@gmail.com> <mailto:brbrof...@gmail.com 
<mailto:brbrof...@gmail.com>>>:

 OK, here's the updated trials.pd with appropriate phase 
relationships. The pulse train in SC3 is control rate, so there might be a ramp 
between values that I'm missing. You can add it and see if it makes a 
difference.

 On Tue, Feb 16, 2016 at 9:49 AM, Matt Barber <brbrof...@gmail.com 
<mailto:brbrof...@gmail.com> <mailto:brbrof...@gmail.com 
<mailto:brbrof...@gmail.com>>> wrote:

 The documentation is poor on both sides. I had to go into 
the source code to find out a couple of things.

 On Feb 16, 2016 9:45 AM, "Alexandre Torres Porres" <por...@gmail.com 
<mailto:por...@gmail.com> <mailto:por...@gmail.com <mailto:por...@gmail.com>>> wrote:

 yeah, just checked them and they sound quite the same 
now ;) I wonder how I screwed up

 2016-02-16 12:39 GMT-02:00 Matt Barber <brbrof...@gmail.com 
<mailto:brbrof...@gmail.com> <mailto:brbrof...@gmail.com 
<mailto:brbrof...@gmail.com>>>:

 Yeah, the phase relationships didn't match those 
in the SC3 code. I'll send the updated patch when I can get to my computer.

 On Feb 16, 2016 9:36 AM, "Alexandre Torres Porres" <por...@gmail.com 
<mailto:por...@gmail.com> <mailto:por...@gmail.com <mailto:por...@gmail.com>>> wrote:

  > OK, I had to adjust the Pd patch a little 
to get it to match the SC3 code.

 why? what do you mean? was it wrong?

 2016-02-16 6:07 GMT-02:00 Matt Barber <brbrof...@gmail.com 
<mailto:brbrof...@gmail.com> <mailto:brbrof...@gmail.com 
<mailto:brbrof...@gmail.com>>>:

 OK, I had to adjust the Pd patch a little 
to get it to match the SC3 code. I've made an A/B test: one is SC3 and the 
other is the matching Pd patch. See if you can tell which one is which, and why 
you answered the way you did. I went fast and made them 44.1kHz 16-bit; you'll 
have to live with it. :)

 On Mon, Feb 15, 2016 at 11:55 PM, Alexandre Torres Porres 
<por...@gmail.com <mailto:por...@gmail.com> <mailto:por...@gmail.com 
<mailto:por...@gmail.com>>> wrote:

 correct code

 {VarSaw.ar(LFPulse.kr(1, 0, 0.3, 50, 
50), 0, LFTri.ar(1, 

Re: [PD] Does Pd have a "sound"?

[Matt Barber]

They won't sound bad, necessarily; they just won't sound band limited.
(Everything has its place.)
On Feb 16, 2016 1:29 PM, "cyrille henry"  wrote:

> if you want to compare the "sound" of SC and pd, please use band limited
> operator, or both will sound bad.
>
> cheers
> c
>
>
> Le 16/02/2016 19:16, Matt Barber a écrit :
>
>> Sure, send 'em along. It's good for learning. I've heard so many times
>> that "SC3 just sounds better," and I'm a skeptic overall. I have a few
>> comparisons of my own to try soon.
>>
>> On Tue, Feb 16, 2016 at 12:53 PM, Alexandre Torres Porres <
>> por...@gmail.com > wrote:
>>
>> Cool, but you see, I suspected SuperCollider would do things such as
>> clip the phase from  phase 0.001 to 0.999 to prevent a harsh sawtooth, and
>> also fade in (ramp) one block when a Synth starts.
>>
>> I feel it has many such details to make it sound "smoother" and
>> nicer, it also seems to be a little quieter
>>
>> well, I kind like this, if I have other patches to compare, would you
>> like to check? :)
>>
>> cheers
>>
>> 2016-02-16 14:53 GMT-02:00 Matt Barber  brbrof...@gmail.com>>:
>>
>> OK, here's the updated trials.pd with appropriate phase
>> relationships. The pulse train in SC3 is control rate, so there might be a
>> ramp between values that I'm missing. You can add it and see if it makes a
>> difference.
>>
>> On Tue, Feb 16, 2016 at 9:49 AM, Matt Barber > > wrote:
>>
>> The documentation is poor on both sides. I had to go into the
>> source code to find out a couple of things.
>>
>> On Feb 16, 2016 9:45 AM, "Alexandre Torres Porres" <
>> por...@gmail.com > wrote:
>>
>> yeah, just checked them and they sound quite the same now
>> ;) I wonder how I screwed up
>>
>> 2016-02-16 12:39 GMT-02:00 Matt Barber <
>> brbrof...@gmail.com >:
>>
>> Yeah, the phase relationships didn't match those in
>> the SC3 code. I'll send the updated patch when I can get to my computer.
>>
>> On Feb 16, 2016 9:36 AM, "Alexandre Torres Porres" <
>> por...@gmail.com > wrote:
>>
>>  > OK, I had to adjust the Pd patch a little to
>> get it to match the SC3 code.
>>
>> why? what do you mean? was it wrong?
>>
>> 2016-02-16 6:07 GMT-02:00 Matt Barber <
>> brbrof...@gmail.com >:
>>
>> OK, I had to adjust the Pd patch a little to
>> get it to match the SC3 code. I've made an A/B test: one is SC3 and the
>> other is the matching Pd patch. See if you can tell which one is which, and
>> why you answered the way you did. I went fast and made them 44.1kHz 16-bit;
>> you'll have to live with it. :)
>>
>> On Mon, Feb 15, 2016 at 11:55 PM, Alexandre
>> Torres Porres > wrote:
>>
>> correct code
>>
>> {VarSaw.ar(LFPulse.kr(1, 0, 0.3, 50, 50),
>> 0, LFTri.ar(1, 0, 0.5, 0.5))!2}.play
>>
>> 2016-02-16 2:54 GMT-02:00 Alexandre
>> Torres Porres >:
>>
>> well, while we're at it, here's the
>> patches for you to check and speculate :)
>>
>>
>> SuperCollider Code;
>> VarSaw.ar(LFPulse.kr(1, 0, 0.3, 50,
>> 50), 0, LFTri.ar(1, 0, 0.5, 0.5))!2.play
>>
>> 2016-02-16 2:45 GMT-02:00 Matt Barber
>> >:
>>
>> If there is difference between
>> the sound of [triangle~] and VarSaw, it might actually be in the way phase
>> is generated. The algorithms themselves are pretty much the same, but while
>> VarSaw makes its own single-precision phase by simply subtracting 1 when an
>> increment takes it past 1.0 (using a conditional on each sample),
>> [triangle~] is a waveshaper that is fed phase. Pd's phasor is a little
>> idiosyncratic, using a kind of bit-hacking to unwrap phase (the Höldrich
>> method), which is supposed to perform a bit faster than a conditional, and
>> it's inside not just [phasor~] but all the oscillator objects. If I
>> remember correctly it can be prone to phase drift over time, but don't
>> quote me on that.
>>
>> On Mon, Feb 15, 2016 at 11:24 AM,
>> Alexandre Torres Porres >
>> wrote:
>>
>> I still believe differences
>> between Pd and SC depend on other technical details than the ones
>> presented, because similar objects like 

Re: [PD] Does Pd have a "sound"?

[cyrille henry]

if you want to compare the "sound" of SC and pd, please use band limited 
operator, or both will sound bad.

cheers
c


Le 16/02/2016 19:16, Matt Barber a écrit :

Sure, send 'em along. It's good for learning. I've heard so many times that "SC3 
just sounds better," and I'm a skeptic overall. I have a few comparisons of my own 
to try soon.

On Tue, Feb 16, 2016 at 12:53 PM, Alexandre Torres Porres > wrote:

Cool, but you see, I suspected SuperCollider would do things such as clip 
the phase from  phase 0.001 to 0.999 to prevent a harsh sawtooth, and also fade 
in (ramp) one block when a Synth starts.

I feel it has many such details to make it sound "smoother" and nicer, it 
also seems to be a little quieter

well, I kind like this, if I have other patches to compare, would you like 
to check? :)

cheers

2016-02-16 14:53 GMT-02:00 Matt Barber >:

OK, here's the updated trials.pd with appropriate phase relationships. 
The pulse train in SC3 is control rate, so there might be a ramp between values 
that I'm missing. You can add it and see if it makes a difference.

On Tue, Feb 16, 2016 at 9:49 AM, Matt Barber > wrote:

The documentation is poor on both sides. I had to go into the 
source code to find out a couple of things.

On Feb 16, 2016 9:45 AM, "Alexandre Torres Porres" > wrote:

yeah, just checked them and they sound quite the same now ;) I 
wonder how I screwed up

2016-02-16 12:39 GMT-02:00 Matt Barber >:

Yeah, the phase relationships didn't match those in the SC3 
code. I'll send the updated patch when I can get to my computer.

On Feb 16, 2016 9:36 AM, "Alexandre Torres Porres" > wrote:

 > OK, I had to adjust the Pd patch a little to get it 
to match the SC3 code.

why? what do you mean? was it wrong?

2016-02-16 6:07 GMT-02:00 Matt Barber >:

OK, I had to adjust the Pd patch a little to get it 
to match the SC3 code. I've made an A/B test: one is SC3 and the other is the 
matching Pd patch. See if you can tell which one is which, and why you answered 
the way you did. I went fast and made them 44.1kHz 16-bit; you'll have to live 
with it. :)

On Mon, Feb 15, 2016 at 11:55 PM, Alexandre Torres Porres 
> wrote:

correct code

{VarSaw.ar(LFPulse.kr(1, 0, 0.3, 50, 50), 0, 
LFTri.ar(1, 0, 0.5, 0.5))!2}.play

2016-02-16 2:54 GMT-02:00 Alexandre Torres Porres 
>:

well, while we're at it, here's the patches 
for you to check and speculate :)


SuperCollider Code;
VarSaw.ar(LFPulse.kr(1, 0, 0.3, 50, 50), 0, 
LFTri.ar(1, 0, 0.5, 0.5))!2.play

2016-02-16 2:45 GMT-02:00 Matt Barber 
>:

If there is difference between the 
sound of [triangle~] and VarSaw, it might actually be in the way phase is 
generated. The algorithms themselves are pretty much the same, but while VarSaw 
makes its own single-precision phase by simply subtracting 1 when an increment 
takes it past 1.0 (using a conditional on each sample), [triangle~] is a 
waveshaper that is fed phase. Pd's phasor is a little idiosyncratic, using a 
kind of bit-hacking to unwrap phase (the Höldrich method), which is supposed to 
perform a bit faster than a conditional, and it's inside not just [phasor~] but 
all the oscillator objects. If I remember correctly it can be prone to phase 
drift over time, but don't quote me on that.

On Mon, Feb 15, 2016 at 11:24 AM, Alexandre Torres 
Porres > wrote:

I still believe differences between Pd and SC 
depend on other technical details than the ones presented, because similar objects like 
triangle~ and VarSaw will just sound quite differently, hence it may rely on subtleties 
inside the objects themselves. And I'm not talking about the "cultural" use 
which is something I believe makes quite a difference even in the Pd x Max world (when 
they both sound quite similar).

cheers

2016-02-15 13:54 GMT-02:00 Andy 

Re: [PD] Does Pd have a "sound"?

[Alexandre Torres Porres]

well, I feel it sounds better, but I wonder why... I guess it's in the
object level, so we could just clone them :)

2016-02-16 16:16 GMT-02:00 Matt Barber :

> Sure, send 'em along. It's good for learning. I've heard so many times
> that "SC3 just sounds better," and I'm a skeptic overall. I have a few
> comparisons of my own to try soon.
>
> On Tue, Feb 16, 2016 at 12:53 PM, Alexandre Torres Porres <
> por...@gmail.com> wrote:
>
>> Cool, but you see, I suspected SuperCollider would do things such as clip
>> the phase from  phase 0.001 to 0.999 to prevent a harsh sawtooth, and also
>> fade in (ramp) one block when a Synth starts.
>>
>> I feel it has many such details to make it sound "smoother" and nicer, it
>> also seems to be a little quieter
>>
>> well, I kind like this, if I have other patches to compare, would you
>> like to check? :)
>>
>> cheers
>>
>> 2016-02-16 14:53 GMT-02:00 Matt Barber :
>>
>>> OK, here's the updated trials.pd with appropriate phase relationships.
>>> The pulse train in SC3 is control rate, so there might be a ramp between
>>> values that I'm missing. You can add it and see if it makes a difference.
>>>
>>> On Tue, Feb 16, 2016 at 9:49 AM, Matt Barber 
>>> wrote:
>>>
 The documentation is poor on both sides. I had to go into the source
 code to find out a couple of things.
 On Feb 16, 2016 9:45 AM, "Alexandre Torres Porres" 
 wrote:

> yeah, just checked them and they sound quite the same now ;) I wonder
> how I screwed up
>
> 2016-02-16 12:39 GMT-02:00 Matt Barber :
>
>> Yeah, the phase relationships didn't match those in the SC3 code.
>> I'll send the updated patch when I can get to my computer.
>> On Feb 16, 2016 9:36 AM, "Alexandre Torres Porres" 
>> wrote:
>>
>>> > OK, I had to adjust the Pd patch a little to get it to match the
>>> SC3 code.
>>>
>>> why? what do you mean? was it wrong?
>>>
>>> 2016-02-16 6:07 GMT-02:00 Matt Barber :
>>>
 OK, I had to adjust the Pd patch a little to get it to match the
 SC3 code. I've made an A/B test: one is SC3 and the other is the 
 matching
 Pd patch. See if you can tell which one is which, and why you answered 
 the
 way you did. I went fast and made them 44.1kHz 16-bit; you'll have to 
 live
 with it. :)

 On Mon, Feb 15, 2016 at 11:55 PM, Alexandre Torres Porres <
 por...@gmail.com> wrote:

> correct code
>
> {VarSaw.ar(LFPulse.kr(1, 0, 0.3, 50, 50), 0, LFTri.ar(1, 0, 0.5,
> 0.5))!2}.play
>
> 2016-02-16 2:54 GMT-02:00 Alexandre Torres Porres <
> por...@gmail.com>:
>
>> well, while we're at it, here's the patches for you to check and
>> speculate :)
>>
>>
>> SuperCollider Code;
>> VarSaw.ar(LFPulse.kr(1, 0, 0.3, 50, 50), 0, LFTri.ar(1, 0, 0.5,
>> 0.5))!2.play
>>
>> 2016-02-16 2:45 GMT-02:00 Matt Barber :
>>
>>> If there is difference between the sound of [triangle~] and
>>> VarSaw, it might actually be in the way phase is generated. The 
>>> algorithms
>>> themselves are pretty much the same, but while VarSaw makes its own
>>> single-precision phase by simply subtracting 1 when an increment 
>>> takes it
>>> past 1.0 (using a conditional on each sample), [triangle~] is a 
>>> waveshaper
>>> that is fed phase. Pd's phasor is a little idiosyncratic, using a 
>>> kind of
>>> bit-hacking to unwrap phase (the Höldrich method), which is 
>>> supposed to
>>> perform a bit faster than a conditional, and it's inside not just 
>>> [phasor~]
>>> but all the oscillator objects. If I remember correctly it can be 
>>> prone to
>>> phase drift over time, but don't quote me on that.
>>>
>>> On Mon, Feb 15, 2016 at 11:24 AM, Alexandre Torres Porres <
>>> por...@gmail.com> wrote:
>>>
 I still believe differences between Pd and SC depend on other
 technical details than the ones presented, because similar objects 
 like
 triangle~ and VarSaw will just sound quite differently, hence it 
 may rely
 on subtleties inside the objects themselves. And I'm not talking 
 about the
 "cultural" use which is something I believe makes quite a 
 difference even
 in the Pd x Max world (when they both sound quite similar).

 cheers

 2016-02-15 13:54 GMT-02:00 Andy Farnell <
 padawa...@obiwannabe.co.uk>:

>
> 

Re: [PD] Does Pd have a "sound"?

[Matt Barber]

Sure, send 'em along. It's good for learning. I've heard so many times that
"SC3 just sounds better," and I'm a skeptic overall. I have a few
comparisons of my own to try soon.

On Tue, Feb 16, 2016 at 12:53 PM, Alexandre Torres Porres 
wrote:

> Cool, but you see, I suspected SuperCollider would do things such as clip
> the phase from  phase 0.001 to 0.999 to prevent a harsh sawtooth, and also
> fade in (ramp) one block when a Synth starts.
>
> I feel it has many such details to make it sound "smoother" and nicer, it
> also seems to be a little quieter
>
> well, I kind like this, if I have other patches to compare, would you like
> to check? :)
>
> cheers
>
> 2016-02-16 14:53 GMT-02:00 Matt Barber :
>
>> OK, here's the updated trials.pd with appropriate phase relationships.
>> The pulse train in SC3 is control rate, so there might be a ramp between
>> values that I'm missing. You can add it and see if it makes a difference.
>>
>> On Tue, Feb 16, 2016 at 9:49 AM, Matt Barber  wrote:
>>
>>> The documentation is poor on both sides. I had to go into the source
>>> code to find out a couple of things.
>>> On Feb 16, 2016 9:45 AM, "Alexandre Torres Porres" 
>>> wrote:
>>>
 yeah, just checked them and they sound quite the same now ;) I wonder
 how I screwed up

 2016-02-16 12:39 GMT-02:00 Matt Barber :

> Yeah, the phase relationships didn't match those in the SC3 code. I'll
> send the updated patch when I can get to my computer.
> On Feb 16, 2016 9:36 AM, "Alexandre Torres Porres" 
> wrote:
>
>> > OK, I had to adjust the Pd patch a little to get it to match the
>> SC3 code.
>>
>> why? what do you mean? was it wrong?
>>
>> 2016-02-16 6:07 GMT-02:00 Matt Barber :
>>
>>> OK, I had to adjust the Pd patch a little to get it to match the SC3
>>> code. I've made an A/B test: one is SC3 and the other is the matching Pd
>>> patch. See if you can tell which one is which, and why you answered the 
>>> way
>>> you did. I went fast and made them 44.1kHz 16-bit; you'll have to live 
>>> with
>>> it. :)
>>>
>>> On Mon, Feb 15, 2016 at 11:55 PM, Alexandre Torres Porres <
>>> por...@gmail.com> wrote:
>>>
 correct code

 {VarSaw.ar(LFPulse.kr(1, 0, 0.3, 50, 50), 0, LFTri.ar(1, 0, 0.5,
 0.5))!2}.play

 2016-02-16 2:54 GMT-02:00 Alexandre Torres Porres :

> well, while we're at it, here's the patches for you to check and
> speculate :)
>
>
> SuperCollider Code;
> VarSaw.ar(LFPulse.kr(1, 0, 0.3, 50, 50), 0, LFTri.ar(1, 0, 0.5,
> 0.5))!2.play
>
> 2016-02-16 2:45 GMT-02:00 Matt Barber :
>
>> If there is difference between the sound of [triangle~] and
>> VarSaw, it might actually be in the way phase is generated. The 
>> algorithms
>> themselves are pretty much the same, but while VarSaw makes its own
>> single-precision phase by simply subtracting 1 when an increment 
>> takes it
>> past 1.0 (using a conditional on each sample), [triangle~] is a 
>> waveshaper
>> that is fed phase. Pd's phasor is a little idiosyncratic, using a 
>> kind of
>> bit-hacking to unwrap phase (the Höldrich method), which is supposed 
>> to
>> perform a bit faster than a conditional, and it's inside not just 
>> [phasor~]
>> but all the oscillator objects. If I remember correctly it can be 
>> prone to
>> phase drift over time, but don't quote me on that.
>>
>> On Mon, Feb 15, 2016 at 11:24 AM, Alexandre Torres Porres <
>> por...@gmail.com> wrote:
>>
>>> I still believe differences between Pd and SC depend on other
>>> technical details than the ones presented, because similar objects 
>>> like
>>> triangle~ and VarSaw will just sound quite differently, hence it 
>>> may rely
>>> on subtleties inside the objects themselves. And I'm not talking 
>>> about the
>>> "cultural" use which is something I believe makes quite a 
>>> difference even
>>> in the Pd x Max world (when they both sound quite similar).
>>>
>>> cheers
>>>
>>> 2016-02-15 13:54 GMT-02:00 Andy Farnell <
>>> padawa...@obiwannabe.co.uk>:
>>>

 Good list of technical peculiarities Claude. For me, the
 "sound" is those
 quirks combined with how Chris describes a "cultural" or
 "contextual" use.
 I used to be great at knowing the sound of software or hardware
 sources
 and could spot 

Re: [PD] Does Pd have a "sound"?

[Alexandre Torres Porres]

Cool, but you see, I suspected SuperCollider would do things such as clip
the phase from  phase 0.001 to 0.999 to prevent a harsh sawtooth, and also
fade in (ramp) one block when a Synth starts.

I feel it has many such details to make it sound "smoother" and nicer, it
also seems to be a little quieter

well, I kind like this, if I have other patches to compare, would you like
to check? :)

cheers

2016-02-16 14:53 GMT-02:00 Matt Barber :

> OK, here's the updated trials.pd with appropriate phase relationships. The
> pulse train in SC3 is control rate, so there might be a ramp between values
> that I'm missing. You can add it and see if it makes a difference.
>
> On Tue, Feb 16, 2016 at 9:49 AM, Matt Barber  wrote:
>
>> The documentation is poor on both sides. I had to go into the source code
>> to find out a couple of things.
>> On Feb 16, 2016 9:45 AM, "Alexandre Torres Porres" 
>> wrote:
>>
>>> yeah, just checked them and they sound quite the same now ;) I wonder
>>> how I screwed up
>>>
>>> 2016-02-16 12:39 GMT-02:00 Matt Barber :
>>>
 Yeah, the phase relationships didn't match those in the SC3 code. I'll
 send the updated patch when I can get to my computer.
 On Feb 16, 2016 9:36 AM, "Alexandre Torres Porres" 
 wrote:

> > OK, I had to adjust the Pd patch a little to get it to match the
> SC3 code.
>
> why? what do you mean? was it wrong?
>
> 2016-02-16 6:07 GMT-02:00 Matt Barber :
>
>> OK, I had to adjust the Pd patch a little to get it to match the SC3
>> code. I've made an A/B test: one is SC3 and the other is the matching Pd
>> patch. See if you can tell which one is which, and why you answered the 
>> way
>> you did. I went fast and made them 44.1kHz 16-bit; you'll have to live 
>> with
>> it. :)
>>
>> On Mon, Feb 15, 2016 at 11:55 PM, Alexandre Torres Porres <
>> por...@gmail.com> wrote:
>>
>>> correct code
>>>
>>> {VarSaw.ar(LFPulse.kr(1, 0, 0.3, 50, 50), 0, LFTri.ar(1, 0, 0.5,
>>> 0.5))!2}.play
>>>
>>> 2016-02-16 2:54 GMT-02:00 Alexandre Torres Porres 
>>> :
>>>
 well, while we're at it, here's the patches for you to check and
 speculate :)


 SuperCollider Code;
 VarSaw.ar(LFPulse.kr(1, 0, 0.3, 50, 50), 0, LFTri.ar(1, 0, 0.5,
 0.5))!2.play

 2016-02-16 2:45 GMT-02:00 Matt Barber :

> If there is difference between the sound of [triangle~] and
> VarSaw, it might actually be in the way phase is generated. The 
> algorithms
> themselves are pretty much the same, but while VarSaw makes its own
> single-precision phase by simply subtracting 1 when an increment 
> takes it
> past 1.0 (using a conditional on each sample), [triangle~] is a 
> waveshaper
> that is fed phase. Pd's phasor is a little idiosyncratic, using a 
> kind of
> bit-hacking to unwrap phase (the Höldrich method), which is supposed 
> to
> perform a bit faster than a conditional, and it's inside not just 
> [phasor~]
> but all the oscillator objects. If I remember correctly it can be 
> prone to
> phase drift over time, but don't quote me on that.
>
> On Mon, Feb 15, 2016 at 11:24 AM, Alexandre Torres Porres <
> por...@gmail.com> wrote:
>
>> I still believe differences between Pd and SC depend on other
>> technical details than the ones presented, because similar objects 
>> like
>> triangle~ and VarSaw will just sound quite differently, hence it may 
>> rely
>> on subtleties inside the objects themselves. And I'm not talking 
>> about the
>> "cultural" use which is something I believe makes quite a difference 
>> even
>> in the Pd x Max world (when they both sound quite similar).
>>
>> cheers
>>
>> 2016-02-15 13:54 GMT-02:00 Andy Farnell <
>> padawa...@obiwannabe.co.uk>:
>>
>>>
>>> Good list of technical peculiarities Claude. For me, the "sound"
>>> is those
>>> quirks combined with how Chris describes a "cultural" or
>>> "contextual" use.
>>> I used to be great at knowing the sound of software or hardware
>>> sources
>>> and could spot Reaktor, or a Roland analogue in moments. But
>>> emulations
>>> got better and my ears got older, and maybe I began to care less
>>> about
>>> implementation and more about artistic intent. As Chris says,
>>> different tools tend to make you think and work in certain
>>> patterns,
>>> and I think it is this more than anything that 

Re: [PD] Does Pd have a "sound"?

[Matt Barber]

OK, here's the updated trials.pd with appropriate phase relationships. The
pulse train in SC3 is control rate, so there might be a ramp between values
that I'm missing. You can add it and see if it makes a difference.

On Tue, Feb 16, 2016 at 9:49 AM, Matt Barber  wrote:

> The documentation is poor on both sides. I had to go into the source code
> to find out a couple of things.
> On Feb 16, 2016 9:45 AM, "Alexandre Torres Porres" 
> wrote:
>
>> yeah, just checked them and they sound quite the same now ;) I wonder how
>> I screwed up
>>
>> 2016-02-16 12:39 GMT-02:00 Matt Barber :
>>
>>> Yeah, the phase relationships didn't match those in the SC3 code. I'll
>>> send the updated patch when I can get to my computer.
>>> On Feb 16, 2016 9:36 AM, "Alexandre Torres Porres" 
>>> wrote:
>>>
 > OK, I had to adjust the Pd patch a little to get it to match the SC3
 code.

 why? what do you mean? was it wrong?

 2016-02-16 6:07 GMT-02:00 Matt Barber :

> OK, I had to adjust the Pd patch a little to get it to match the SC3
> code. I've made an A/B test: one is SC3 and the other is the matching Pd
> patch. See if you can tell which one is which, and why you answered the 
> way
> you did. I went fast and made them 44.1kHz 16-bit; you'll have to live 
> with
> it. :)
>
> On Mon, Feb 15, 2016 at 11:55 PM, Alexandre Torres Porres <
> por...@gmail.com> wrote:
>
>> correct code
>>
>> {VarSaw.ar(LFPulse.kr(1, 0, 0.3, 50, 50), 0, LFTri.ar(1, 0, 0.5,
>> 0.5))!2}.play
>>
>> 2016-02-16 2:54 GMT-02:00 Alexandre Torres Porres :
>>
>>> well, while we're at it, here's the patches for you to check and
>>> speculate :)
>>>
>>>
>>> SuperCollider Code;
>>> VarSaw.ar(LFPulse.kr(1, 0, 0.3, 50, 50), 0, LFTri.ar(1, 0, 0.5,
>>> 0.5))!2.play
>>>
>>> 2016-02-16 2:45 GMT-02:00 Matt Barber :
>>>
 If there is difference between the sound of [triangle~] and VarSaw,
 it might actually be in the way phase is generated. The algorithms
 themselves are pretty much the same, but while VarSaw makes its own
 single-precision phase by simply subtracting 1 when an increment takes 
 it
 past 1.0 (using a conditional on each sample), [triangle~] is a 
 waveshaper
 that is fed phase. Pd's phasor is a little idiosyncratic, using a kind 
 of
 bit-hacking to unwrap phase (the Höldrich method), which is supposed to
 perform a bit faster than a conditional, and it's inside not just 
 [phasor~]
 but all the oscillator objects. If I remember correctly it can be 
 prone to
 phase drift over time, but don't quote me on that.

 On Mon, Feb 15, 2016 at 11:24 AM, Alexandre Torres Porres <
 por...@gmail.com> wrote:

> I still believe differences between Pd and SC depend on other
> technical details than the ones presented, because similar objects 
> like
> triangle~ and VarSaw will just sound quite differently, hence it may 
> rely
> on subtleties inside the objects themselves. And I'm not talking 
> about the
> "cultural" use which is something I believe makes quite a difference 
> even
> in the Pd x Max world (when they both sound quite similar).
>
> cheers
>
> 2016-02-15 13:54 GMT-02:00 Andy Farnell <
> padawa...@obiwannabe.co.uk>:
>
>>
>> Good list of technical peculiarities Claude. For me, the "sound"
>> is those
>> quirks combined with how Chris describes a "cultural" or
>> "contextual" use.
>> I used to be great at knowing the sound of software or hardware
>> sources
>> and could spot Reaktor, or a Roland analogue in moments. But
>> emulations
>> got better and my ears got older, and maybe I began to care less
>> about
>> implementation and more about artistic intent. As Chris says,
>> different tools tend to make you think and work in certain
>> patterns,
>> and I think it is this more than anything that constitutes a
>> "sound".
>>
>> cheers
>> Andy
>>
>>
>> ___
>> 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
>
>

>>>
>>
>

>>

Re: [PD] Does Pd have a "sound"?

[cyrille henry]

Le 16/02/2016 16:33, i go bananas a écrit :


The filters are also very rudimentary (although, the new bob~ one looks more 
promising).  Of course it is possible to write your own with the filter 
primitives, but it's hard work.


it's however easy to try one of the many filter provide by the community.

cheers
c

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Does Pd have a "sound"?

[i go bananas]

Kinda weird onservation, but i seriously think pd would 'sound' different
if the standard UI came with a dark background and light objects.  As a few
people have pointed out, the interface does have a noticable influence on
the user.

Also, the default 64 sample blocksize, and the relatively expensive cpu
cost of upsampling or decreasing the blocksize do have noticable impact on
the fidelity.

The filters are also very rudimentary (although, the new bob~ one looks
more promising).  Of course it is possible to write your own with the
filter primitives, but it's hard work.

Something else:  being open source, means that the info and resources are
put together by the community with nobody really comitted full time to the
job of keeping it all together.  The big commercial alternatives all have
staff employed just to herd the users together and make sure their
resources get shared as well as possible.  Pd community is a bit stuck
together with paper clips in that regard.

But on the flip side, pd's community of users is probably the single most
awesome single group of people i have ever had the fortune of being a part
of.  Whenever you get stuck with something, there's always someone to lend
a hand, and whenever you help someone else, they generally are very
grateful.
And the limitations of not having a huge library of readymade techno tools,
is actually a real blessing.  In many ways, pd inspires out of the box
thinking.
In many ways it's easier to set up weird interactive interfaces and
algorithmic compositions than writing boring house music.  Personally i
would call that a plus.

Sorry, know this has gone pretty far off topic.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Does Pd have a "sound"?

[Matt Barber]

The documentation is poor on both sides. I had to go into the source code
to find out a couple of things.
On Feb 16, 2016 9:45 AM, "Alexandre Torres Porres"  wrote:

> yeah, just checked them and they sound quite the same now ;) I wonder how
> I screwed up
>
> 2016-02-16 12:39 GMT-02:00 Matt Barber :
>
>> Yeah, the phase relationships didn't match those in the SC3 code. I'll
>> send the updated patch when I can get to my computer.
>> On Feb 16, 2016 9:36 AM, "Alexandre Torres Porres" 
>> wrote:
>>
>>> > OK, I had to adjust the Pd patch a little to get it to match the SC3
>>> code.
>>>
>>> why? what do you mean? was it wrong?
>>>
>>> 2016-02-16 6:07 GMT-02:00 Matt Barber :
>>>
 OK, I had to adjust the Pd patch a little to get it to match the SC3
 code. I've made an A/B test: one is SC3 and the other is the matching Pd
 patch. See if you can tell which one is which, and why you answered the way
 you did. I went fast and made them 44.1kHz 16-bit; you'll have to live with
 it. :)

 On Mon, Feb 15, 2016 at 11:55 PM, Alexandre Torres Porres <
 por...@gmail.com> wrote:

> correct code
>
> {VarSaw.ar(LFPulse.kr(1, 0, 0.3, 50, 50), 0, LFTri.ar(1, 0, 0.5,
> 0.5))!2}.play
>
> 2016-02-16 2:54 GMT-02:00 Alexandre Torres Porres :
>
>> well, while we're at it, here's the patches for you to check and
>> speculate :)
>>
>>
>> SuperCollider Code;
>> VarSaw.ar(LFPulse.kr(1, 0, 0.3, 50, 50), 0, LFTri.ar(1, 0, 0.5,
>> 0.5))!2.play
>>
>> 2016-02-16 2:45 GMT-02:00 Matt Barber :
>>
>>> If there is difference between the sound of [triangle~] and VarSaw,
>>> it might actually be in the way phase is generated. The algorithms
>>> themselves are pretty much the same, but while VarSaw makes its own
>>> single-precision phase by simply subtracting 1 when an increment takes 
>>> it
>>> past 1.0 (using a conditional on each sample), [triangle~] is a 
>>> waveshaper
>>> that is fed phase. Pd's phasor is a little idiosyncratic, using a kind 
>>> of
>>> bit-hacking to unwrap phase (the Höldrich method), which is supposed to
>>> perform a bit faster than a conditional, and it's inside not just 
>>> [phasor~]
>>> but all the oscillator objects. If I remember correctly it can be prone 
>>> to
>>> phase drift over time, but don't quote me on that.
>>>
>>> On Mon, Feb 15, 2016 at 11:24 AM, Alexandre Torres Porres <
>>> por...@gmail.com> wrote:
>>>
 I still believe differences between Pd and SC depend on other
 technical details than the ones presented, because similar objects like
 triangle~ and VarSaw will just sound quite differently, hence it may 
 rely
 on subtleties inside the objects themselves. And I'm not talking about 
 the
 "cultural" use which is something I believe makes quite a difference 
 even
 in the Pd x Max world (when they both sound quite similar).

 cheers

 2016-02-15 13:54 GMT-02:00 Andy Farnell :

>
> Good list of technical peculiarities Claude. For me, the "sound"
> is those
> quirks combined with how Chris describes a "cultural" or
> "contextual" use.
> I used to be great at knowing the sound of software or hardware
> sources
> and could spot Reaktor, or a Roland analogue in moments. But
> emulations
> got better and my ears got older, and maybe I began to care less
> about
> implementation and more about artistic intent. As Chris says,
> different tools tend to make you think and work in certain
> patterns,
> and I think it is this more than anything that constitutes a
> "sound".
>
> cheers
> Andy
>
>
> ___
> 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


>>>
>>
>

>>>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Does Pd have a "sound"?

[IOhannes m zmoelnig]

On 2016-02-16 15:39, Alexandre Torres Porres wrote:
> But it's quite a pain to being forced to use it and then every time you
> want to use a particular external you must do it, save the patch, close it,
> then re open so you can finally have that external, no matter if you had
> the library installed. Specially if that is actually unnecessary. I had
> never seen that in my Pd years, I think it's really weird.

as you are certainly aware (i think it has been mentioned a few times),
this has been fixed in git (and will be available for the public
audience starting with Pd-0.47)

gasmdr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Does Pd have a "sound"?

[Alexandre Torres Porres]

yeah, just checked them and they sound quite the same now ;) I wonder how I
screwed up

2016-02-16 12:39 GMT-02:00 Matt Barber :

> Yeah, the phase relationships didn't match those in the SC3 code. I'll
> send the updated patch when I can get to my computer.
> On Feb 16, 2016 9:36 AM, "Alexandre Torres Porres" 
> wrote:
>
>> > OK, I had to adjust the Pd patch a little to get it to match the SC3
>> code.
>>
>> why? what do you mean? was it wrong?
>>
>> 2016-02-16 6:07 GMT-02:00 Matt Barber :
>>
>>> OK, I had to adjust the Pd patch a little to get it to match the SC3
>>> code. I've made an A/B test: one is SC3 and the other is the matching Pd
>>> patch. See if you can tell which one is which, and why you answered the way
>>> you did. I went fast and made them 44.1kHz 16-bit; you'll have to live with
>>> it. :)
>>>
>>> On Mon, Feb 15, 2016 at 11:55 PM, Alexandre Torres Porres <
>>> por...@gmail.com> wrote:
>>>
 correct code

 {VarSaw.ar(LFPulse.kr(1, 0, 0.3, 50, 50), 0, LFTri.ar(1, 0, 0.5,
 0.5))!2}.play

 2016-02-16 2:54 GMT-02:00 Alexandre Torres Porres :

> well, while we're at it, here's the patches for you to check and
> speculate :)
>
>
> SuperCollider Code;
> VarSaw.ar(LFPulse.kr(1, 0, 0.3, 50, 50), 0, LFTri.ar(1, 0, 0.5,
> 0.5))!2.play
>
> 2016-02-16 2:45 GMT-02:00 Matt Barber :
>
>> If there is difference between the sound of [triangle~] and VarSaw,
>> it might actually be in the way phase is generated. The algorithms
>> themselves are pretty much the same, but while VarSaw makes its own
>> single-precision phase by simply subtracting 1 when an increment takes it
>> past 1.0 (using a conditional on each sample), [triangle~] is a 
>> waveshaper
>> that is fed phase. Pd's phasor is a little idiosyncratic, using a kind of
>> bit-hacking to unwrap phase (the Höldrich method), which is supposed to
>> perform a bit faster than a conditional, and it's inside not just 
>> [phasor~]
>> but all the oscillator objects. If I remember correctly it can be prone 
>> to
>> phase drift over time, but don't quote me on that.
>>
>> On Mon, Feb 15, 2016 at 11:24 AM, Alexandre Torres Porres <
>> por...@gmail.com> wrote:
>>
>>> I still believe differences between Pd and SC depend on other
>>> technical details than the ones presented, because similar objects like
>>> triangle~ and VarSaw will just sound quite differently, hence it may 
>>> rely
>>> on subtleties inside the objects themselves. And I'm not talking about 
>>> the
>>> "cultural" use which is something I believe makes quite a difference 
>>> even
>>> in the Pd x Max world (when they both sound quite similar).
>>>
>>> cheers
>>>
>>> 2016-02-15 13:54 GMT-02:00 Andy Farnell 
>>> :
>>>

 Good list of technical peculiarities Claude. For me, the "sound" is
 those
 quirks combined with how Chris describes a "cultural" or
 "contextual" use.
 I used to be great at knowing the sound of software or hardware
 sources
 and could spot Reaktor, or a Roland analogue in moments. But
 emulations
 got better and my ears got older, and maybe I began to care less
 about
 implementation and more about artistic intent. As Chris says,
 different tools tend to make you think and work in certain patterns,
 and I think it is this more than anything that constitutes a
 "sound".

 cheers
 Andy


 ___
 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
>>>
>>>
>>
>

>>>
>>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Does Pd have a "sound"?

[Alexandre Torres Porres]

On another note about declare, I think it's not a pain in the ass if you're
just using it to make it easier when you're sharing with others.

But it's quite a pain to being forced to use it and then every time you
want to use a particular external you must do it, save the patch, close it,
then re open so you can finally have that external, no matter if you had
the library installed. Specially if that is actually unnecessary. I had
never seen that in my Pd years, I think it's really weird.

2016-02-16 12:35 GMT-02:00 Alexandre Torres Porres :

>
>
> 2016-02-16 6:47 GMT-02:00 cyrille henry :
>
>> hello Alexandre,
>>
>> I don't know where the train~ object came from
>
>
> howdy, it's from cyclone
>
> the triangle~ is also a problem : i've got one on my computer, that came
>> from nusmuk-audio. you use an other one, with a different sound. Mine did
>> not accept the "lo 0" message.
>>
>
> yep, from cyclone too
>
> if you "declare" the lib it came from, then there are more chances that
>> this patch would load on my computer. If not, at least i would know what
>> lib to download.
>>
>
> Well, I know about the need and purpose of a [declare] object, and I'm not
> against it or people who want to use it. When I wanna make it explicit I
> also go like [cyclone/triangle~], works fine as well.
>
> I don't really share that much patches and worry about it, but in the
> patches I make available for my classes, I do specify the Pd version I'm
> using, so if you have it, they'll all load.
>
>
>> chances are that even you, in few years will not remember where does
>> triangle~ came from.
>>
>
> I can personally guarantee there's no chance of that happening :)
> specially because of my involvement with cyclone now, but I also usually
> remember about other externals from other pd extended libraries as I try to
> memorize and rely on not too many.
>
> cheers
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Does Pd have a "sound"?

[Matt Barber]

Yeah, the phase relationships didn't match those in the SC3 code. I'll send
the updated patch when I can get to my computer.
On Feb 16, 2016 9:36 AM, "Alexandre Torres Porres"  wrote:

> > OK, I had to adjust the Pd patch a little to get it to match the SC3
> code.
>
> why? what do you mean? was it wrong?
>
> 2016-02-16 6:07 GMT-02:00 Matt Barber :
>
>> OK, I had to adjust the Pd patch a little to get it to match the SC3
>> code. I've made an A/B test: one is SC3 and the other is the matching Pd
>> patch. See if you can tell which one is which, and why you answered the way
>> you did. I went fast and made them 44.1kHz 16-bit; you'll have to live with
>> it. :)
>>
>> On Mon, Feb 15, 2016 at 11:55 PM, Alexandre Torres Porres <
>> por...@gmail.com> wrote:
>>
>>> correct code
>>>
>>> {VarSaw.ar(LFPulse.kr(1, 0, 0.3, 50, 50), 0, LFTri.ar(1, 0, 0.5,
>>> 0.5))!2}.play
>>>
>>> 2016-02-16 2:54 GMT-02:00 Alexandre Torres Porres :
>>>
 well, while we're at it, here's the patches for you to check and
 speculate :)


 SuperCollider Code;
 VarSaw.ar(LFPulse.kr(1, 0, 0.3, 50, 50), 0, LFTri.ar(1, 0, 0.5,
 0.5))!2.play

 2016-02-16 2:45 GMT-02:00 Matt Barber :

> If there is difference between the sound of [triangle~] and VarSaw, it
> might actually be in the way phase is generated. The algorithms themselves
> are pretty much the same, but while VarSaw makes its own single-precision
> phase by simply subtracting 1 when an increment takes it past 1.0 (using a
> conditional on each sample), [triangle~] is a waveshaper that is fed 
> phase.
> Pd's phasor is a little idiosyncratic, using a kind of bit-hacking to
> unwrap phase (the Höldrich method), which is supposed to perform a bit
> faster than a conditional, and it's inside not just [phasor~] but all the
> oscillator objects. If I remember correctly it can be prone to phase drift
> over time, but don't quote me on that.
>
> On Mon, Feb 15, 2016 at 11:24 AM, Alexandre Torres Porres <
> por...@gmail.com> wrote:
>
>> I still believe differences between Pd and SC depend on other
>> technical details than the ones presented, because similar objects like
>> triangle~ and VarSaw will just sound quite differently, hence it may rely
>> on subtleties inside the objects themselves. And I'm not talking about 
>> the
>> "cultural" use which is something I believe makes quite a difference even
>> in the Pd x Max world (when they both sound quite similar).
>>
>> cheers
>>
>> 2016-02-15 13:54 GMT-02:00 Andy Farnell :
>>
>>>
>>> Good list of technical peculiarities Claude. For me, the "sound" is
>>> those
>>> quirks combined with how Chris describes a "cultural" or
>>> "contextual" use.
>>> I used to be great at knowing the sound of software or hardware
>>> sources
>>> and could spot Reaktor, or a Roland analogue in moments. But
>>> emulations
>>> got better and my ears got older, and maybe I began to care less
>>> about
>>> implementation and more about artistic intent. As Chris says,
>>> different tools tend to make you think and work in certain patterns,
>>> and I think it is this more than anything that constitutes a "sound".
>>>
>>> cheers
>>> Andy
>>>
>>>
>>> ___
>>> 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
>>
>>
>

>>>
>>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Does Pd have a "sound"?

[Alexandre Torres Porres]

2016-02-16 6:47 GMT-02:00 cyrille henry :

> hello Alexandre,
>
> I don't know where the train~ object came from


howdy, it's from cyclone

the triangle~ is also a problem : i've got one on my computer, that came
> from nusmuk-audio. you use an other one, with a different sound. Mine did
> not accept the "lo 0" message.
>

yep, from cyclone too

if you "declare" the lib it came from, then there are more chances that
> this patch would load on my computer. If not, at least i would know what
> lib to download.
>

Well, I know about the need and purpose of a [declare] object, and I'm not
against it or people who want to use it. When I wanna make it explicit I
also go like [cyclone/triangle~], works fine as well.

I don't really share that much patches and worry about it, but in the
patches I make available for my classes, I do specify the Pd version I'm
using, so if you have it, they'll all load.


> chances are that even you, in few years will not remember where does
> triangle~ came from.
>

I can personally guarantee there's no chance of that happening :) specially
because of my involvement with cyclone now, but I also usually remember
about other externals from other pd extended libraries as I try to memorize
and rely on not too many.

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Does Pd have a "sound"?

[Alexandre Torres Porres]

correct code

{VarSaw.ar(LFPulse.kr(1, 0, 0.3, 50, 50), 0, LFTri.ar(1, 0, 0.5,
0.5))!2}.play

2016-02-16 2:54 GMT-02:00 Alexandre Torres Porres :

> well, while we're at it, here's the patches for you to check and speculate
> :)
>
>
> SuperCollider Code;
> VarSaw.ar(LFPulse.kr(1, 0, 0.3, 50, 50), 0, LFTri.ar(1, 0, 0.5,
> 0.5))!2.play
>
> 2016-02-16 2:45 GMT-02:00 Matt Barber :
>
>> If there is difference between the sound of [triangle~] and VarSaw, it
>> might actually be in the way phase is generated. The algorithms themselves
>> are pretty much the same, but while VarSaw makes its own single-precision
>> phase by simply subtracting 1 when an increment takes it past 1.0 (using a
>> conditional on each sample), [triangle~] is a waveshaper that is fed phase.
>> Pd's phasor is a little idiosyncratic, using a kind of bit-hacking to
>> unwrap phase (the Höldrich method), which is supposed to perform a bit
>> faster than a conditional, and it's inside not just [phasor~] but all the
>> oscillator objects. If I remember correctly it can be prone to phase drift
>> over time, but don't quote me on that.
>>
>> On Mon, Feb 15, 2016 at 11:24 AM, Alexandre Torres Porres <
>> por...@gmail.com> wrote:
>>
>>> I still believe differences between Pd and SC depend on other technical
>>> details than the ones presented, because similar objects like triangle~ and
>>> VarSaw will just sound quite differently, hence it may rely on subtleties
>>> inside the objects themselves. And I'm not talking about the "cultural" use
>>> which is something I believe makes quite a difference even in the Pd x Max
>>> world (when they both sound quite similar).
>>>
>>> cheers
>>>
>>> 2016-02-15 13:54 GMT-02:00 Andy Farnell :
>>>

 Good list of technical peculiarities Claude. For me, the "sound" is
 those
 quirks combined with how Chris describes a "cultural" or "contextual"
 use.
 I used to be great at knowing the sound of software or hardware sources
 and could spot Reaktor, or a Roland analogue in moments. But emulations
 got better and my ears got older, and maybe I began to care less about
 implementation and more about artistic intent. As Chris says,
 different tools tend to make you think and work in certain patterns,
 and I think it is this more than anything that constitutes a "sound".

 cheers
 Andy


 ___
 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
>>>
>>>
>>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Does Pd have a "sound"?

[Alexandre Torres Porres]

well, while we're at it, here's the patches for you to check and speculate
:)


SuperCollider Code;
VarSaw.ar(LFPulse.kr(1, 0, 0.3, 50, 50), 0, LFTri.ar(1, 0, 0.5, 0.5))!2.play

2016-02-16 2:45 GMT-02:00 Matt Barber :

> If there is difference between the sound of [triangle~] and VarSaw, it
> might actually be in the way phase is generated. The algorithms themselves
> are pretty much the same, but while VarSaw makes its own single-precision
> phase by simply subtracting 1 when an increment takes it past 1.0 (using a
> conditional on each sample), [triangle~] is a waveshaper that is fed phase.
> Pd's phasor is a little idiosyncratic, using a kind of bit-hacking to
> unwrap phase (the Höldrich method), which is supposed to perform a bit
> faster than a conditional, and it's inside not just [phasor~] but all the
> oscillator objects. If I remember correctly it can be prone to phase drift
> over time, but don't quote me on that.
>
> On Mon, Feb 15, 2016 at 11:24 AM, Alexandre Torres Porres <
> por...@gmail.com> wrote:
>
>> I still believe differences between Pd and SC depend on other technical
>> details than the ones presented, because similar objects like triangle~ and
>> VarSaw will just sound quite differently, hence it may rely on subtleties
>> inside the objects themselves. And I'm not talking about the "cultural" use
>> which is something I believe makes quite a difference even in the Pd x Max
>> world (when they both sound quite similar).
>>
>> cheers
>>
>> 2016-02-15 13:54 GMT-02:00 Andy Farnell :
>>
>>>
>>> Good list of technical peculiarities Claude. For me, the "sound" is those
>>> quirks combined with how Chris describes a "cultural" or "contextual"
>>> use.
>>> I used to be great at knowing the sound of software or hardware sources
>>> and could spot Reaktor, or a Roland analogue in moments. But emulations
>>> got better and my ears got older, and maybe I began to care less about
>>> implementation and more about artistic intent. As Chris says,
>>> different tools tend to make you think and work in certain patterns,
>>> and I think it is this more than anything that constitutes a "sound".
>>>
>>> cheers
>>> Andy
>>>
>>>
>>> ___
>>> 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
>>
>>
>


trials.pd
Description: Binary data
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Does Pd have a "sound"?

[Matt Barber]

If there is difference between the sound of [triangle~] and VarSaw, it
might actually be in the way phase is generated. The algorithms themselves
are pretty much the same, but while VarSaw makes its own single-precision
phase by simply subtracting 1 when an increment takes it past 1.0 (using a
conditional on each sample), [triangle~] is a waveshaper that is fed phase.
Pd's phasor is a little idiosyncratic, using a kind of bit-hacking to
unwrap phase (the Höldrich method), which is supposed to perform a bit
faster than a conditional, and it's inside not just [phasor~] but all the
oscillator objects. If I remember correctly it can be prone to phase drift
over time, but don't quote me on that.

On Mon, Feb 15, 2016 at 11:24 AM, Alexandre Torres Porres 
wrote:

> I still believe differences between Pd and SC depend on other technical
> details than the ones presented, because similar objects like triangle~ and
> VarSaw will just sound quite differently, hence it may rely on subtleties
> inside the objects themselves. And I'm not talking about the "cultural" use
> which is something I believe makes quite a difference even in the Pd x Max
> world (when they both sound quite similar).
>
> cheers
>
> 2016-02-15 13:54 GMT-02:00 Andy Farnell :
>
>>
>> Good list of technical peculiarities Claude. For me, the "sound" is those
>> quirks combined with how Chris describes a "cultural" or "contextual" use.
>> I used to be great at knowing the sound of software or hardware sources
>> and could spot Reaktor, or a Roland analogue in moments. But emulations
>> got better and my ears got older, and maybe I began to care less about
>> implementation and more about artistic intent. As Chris says,
>> different tools tend to make you think and work in certain patterns,
>> and I think it is this more than anything that constitutes a "sound".
>>
>> cheers
>> Andy
>>
>>
>> ___
>> 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
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Does Pd have a "sound"?

[Dan Wilcox]

And this is why many of us prefer it … :)


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Feb 14, 2016, at 8:24 PM, Chris McCormick  wrote:
> 
> As a result a lot of Pd work might be best described as "raw" and "live".

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Does Pd have a "sound"?

[j...@jeanmarie-adrien.net]

lol
Le 15 févr. 2016 à 18:37, david medine  a écrit :

> Well, one could write a book about how to make a triangle wave. I've decided 
> it's impossible.
> 
> On 2/15/16 8:24 AM, Alexandre Torres Porres wrote:
>> I still believe differences between Pd and SC depend on other technical 
>> details than the ones presented, because similar objects like triangle~ and 
>> VarSaw will just sound quite differently, hence it may rely on subtleties 
>> inside the objects themselves. And I'm not talking about the "cultural" use 
>> which is something I believe makes quite a difference even in the Pd x Max 
>> world (when they both sound quite similar).
>> 
>> cheers
>> 
>> 2016-02-15 13:54 GMT-02:00 Andy Farnell :
>> 
>> Good list of technical peculiarities Claude. For me, the "sound" is those
>> quirks combined with how Chris describes a "cultural" or "contextual" use.
>> I used to be great at knowing the sound of software or hardware sources
>> and could spot Reaktor, or a Roland analogue in moments. But emulations
>> got better and my ears got older, and maybe I began to care less about
>> implementation and more about artistic intent. As Chris says,
>> different tools tend to make you think and work in certain patterns,
>> and I think it is this more than anything that constitutes a "sound".
>> 
>> cheers
>> Andy
>> 
>> 
>> ___
>> 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
> 
> ___
> 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

Re: [PD] Does Pd have a "sound"?

[david medine]

Well, one could write a book about how to make a triangle wave. I've 
decided it's impossible.


On 2/15/16 8:24 AM, Alexandre Torres Porres wrote:
I still believe differences between Pd and SC depend on other 
technical details than the ones presented, because similar objects 
like triangle~ and VarSaw will just sound quite differently, hence it 
may rely on subtleties inside the objects themselves. And I'm not 
talking about the "cultural" use which is something I believe makes 
quite a difference even in the Pd x Max world (when they both sound 
quite similar).


cheers

2016-02-15 13:54 GMT-02:00 Andy Farnell >:



Good list of technical peculiarities Claude. For me, the "sound"
is those
quirks combined with how Chris describes a "cultural" or
"contextual" use.
I used to be great at knowing the sound of software or hardware
sources
and could spot Reaktor, or a Roland analogue in moments. But
emulations
got better and my ears got older, and maybe I began to care less about
implementation and more about artistic intent. As Chris says,
different tools tend to make you think and work in certain patterns,
and I think it is this more than anything that constitutes a "sound".

cheers
Andy


___
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


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Does Pd have a "sound"?

[cyrille henry]

hello,

I think that pd did not really have a distinctive sound. But all objects have a 
"sound".
Many in this thread point out objects that can be improve.
But you don't have to use an object if you don't like how it sound : most of 
the time, there are lot's of alternatives.

So, it's up to you to make anything sound "good".

cheers
c


Le 14/02/2016 23:27, Matti Viljamaa a écrit :

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



___
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

Re: [PD] Does Pd have a "sound"?

[Andy Farnell]

Good list of technical peculiarities Claude. For me, the "sound" is those
quirks combined with how Chris describes a "cultural" or "contextual" use.
I used to be great at knowing the sound of software or hardware sources
and could spot Reaktor, or a Roland analogue in moments. But emulations
got better and my ears got older, and maybe I began to care less about
implementation and more about artistic intent. As Chris says,
different tools tend to make you think and work in certain patterns,
and I think it is this more than anything that constitutes a "sound".

cheers
Andy


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Does Pd have a "sound"?

[Alexandre Torres Porres]

can you share the patches? I'd like to see how the interpolation was
implemented

thanks

2016-02-15 13:53 GMT-02:00 Matt Barber :

> Re: cubic interpolation. Yes and no. Pd and csound both use the same
> Lagrange interpolator, which gives discontinuities at segment boundaries,
> but the segments it generates are actually a bit closer to what you would
> expect from sinc interpolation. SC3's Hermite interpolator, which matches
> two points and first derivatives at the boundaries gets rid of the
> discontinuities but at the price of some waveform distortion. The Hermite
> interpolator is also not continuous at the 2nd derivative on boundaries and
> is prone to sudden changes in concavity, while the Lagrange's 2nd
> derivative discontinuities are removable; there are no sudden changes.
>
> You can see this in the screenshot I attached, which demonstrates five
> interpolators in action.
>
> At the very top is the SR/4 cosine wave which serves as the source for the
> interpolators. At the bottom left is what we'd expect from a sinc
> interpolator (I haven't implemented it yet, but it should be very close to
> a cosine wave).
>
> In red are 1) Pd's [tabread4] cubic Lagrange interpolator using an
> array-reading abstraction [array-read4], and 2) The 4-point cubic Hermite
> interpolator [array-read4h]. You can clearly see the 1st-derivative
> discontinuities at the peaks in the former, and the 2nd-derivative
> discontinuities at zero crossings of the latter.
>
> In purple are 1) A 6-point quintic Lagrange interpolator [array-read6], 2)
> A 6-point quintic interpolator [array-read6h] which matches four points and
> first derivatives, and 3) A 6-point quintic interpolator [array-read6h2]
> which matches two points, first derivatives, and second derivatives.
>
> One important thing to notice is how the Lagrange interpolations are much
> closer in overall shape to the cosine wave at bottom left. The cost of
> matching derivatives is a compromise in the shape of the waveform between
> breakpoints.
>
>
> On Mon, Feb 15, 2016 at 9:57 AM, Claude Heiland-Allen 
> wrote:
>
>> On 14/02/16 22:27, Matti Viljamaa wrote:
>>
>>> 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?
>>>
>>
>> Some issues with Pd that affect sound character:
>>
>> 1. cos~ (and osc~) use a small table with linear interpolation, which
>> means there is quite a lot of interpolation noise - I wrote about it here:
>> http://mathr.co.uk/blog/2015-04-21_approximating_cosine.html
>>
>> 2. vcf~ (and probably other recursive filters) use single precision
>> floating point in the feedback loop (pd-double might be different) which
>> causes weird rounding artifacts - I wrote about it here:
>> http://lists.puredata.info/pipermail/pd-list/2010-08/082104.html
>>
>> 3. cubic interpolation (tabread4~ etc) in Pd uses an (imho) incorrect
>> algorithm - it makes a curve that goes through 4 points instead of matching
>> the derivatives at the nearest 2 points, which leads to sharp corners at
>> the original sample points with associated aliasing artifacts - this has
>> been discussed on the lists many times in the past, for example here:
>> http://lists.puredata.info/pipermail/pd-list/2008-06/062864.html and:
>> http://lists.puredata.info/pipermail/pd-list/2010-03/077278.html
>>
>> 4. sig~ (and implicit sig~ from float messages to signal inlets) is
>> steppy and only takes effect at block boundaries - compare with .kr in SC3
>> which is (afaik) linearly interpolated between each block boundary
>>
>> 5. Pd doesn't print enough digits to perfectly reconstruct floating point
>> values when round-tripping through files, so (eg) biquad~ coefficients can
>> become imprecise if you don't write them outside Pd in a text editor
>>
>> 6. other systems tend to come bundled with more nice-sounding stuff like
>> bandlimited oscillators etc, with Pd you tend to have to find externals
>> yourself (deken should make that easier now)
>>
>>
>> Claude
>> --
>> http://mathr.co.uk
>>
>>
>> ___
>> 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
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Does Pd have a "sound"?

[Lorenzo Sutton]

On 14/02/2016 23:27, Matti Viljamaa wrote:

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?


What do *you* think?
What is a (not good) sound?
...
...

:)


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Does Pd have a "sound"?

[Pagano, Patrick]

Yes it does and it make awesome drum machines, nice samplers and gorgeous 
reverbs and delays. A lot of dopes are into modular and feel the need to decry 
the last thing they were into because they are really just fanboys for DSP now 
like they were for baseball cards or other things the collected. I like both 
and pd still is the best computer program ever. Followed by Max then SC3. ❤️

Sent from my iPhone

> On Feb 15, 2016, at 9:57 AM, Claude Heiland-Allen  wrote:
> 
>> On 14/02/16 22:27, Matti Viljamaa wrote:
>> 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?
> 
> Some issues with Pd that affect sound character:
> 
> 1. cos~ (and osc~) use a small table with linear interpolation, which means 
> there is quite a lot of interpolation noise - I wrote about it here: 
> http://mathr.co.uk/blog/2015-04-21_approximating_cosine.html
> 
> 2. vcf~ (and probably other recursive filters) use single precision floating 
> point in the feedback loop (pd-double might be different) which causes weird 
> rounding artifacts - I wrote about it here: 
> http://lists.puredata.info/pipermail/pd-list/2010-08/082104.html
> 
> 3. cubic interpolation (tabread4~ etc) in Pd uses an (imho) incorrect 
> algorithm - it makes a curve that goes through 4 points instead of matching 
> the derivatives at the nearest 2 points, which leads to sharp corners at the 
> original sample points with associated aliasing artifacts - this has been 
> discussed on the lists many times in the past, for example here: 
> http://lists.puredata.info/pipermail/pd-list/2008-06/062864.html and: 
> http://lists.puredata.info/pipermail/pd-list/2010-03/077278.html
> 
> 4. sig~ (and implicit sig~ from float messages to signal inlets) is steppy 
> and only takes effect at block boundaries - compare with .kr in SC3 which is 
> (afaik) linearly interpolated between each block boundary
> 
> 5. Pd doesn't print enough digits to perfectly reconstruct floating point 
> values when round-tripping through files, so (eg) biquad~ coefficients can 
> become imprecise if you don't write them outside Pd in a text editor
> 
> 6. other systems tend to come bundled with more nice-sounding stuff like 
> bandlimited oscillators etc, with Pd you tend to have to find externals 
> yourself (deken should make that easier now)
> 
> 
> Claude
> -- 
> http://mathr.co.uk
> 
> ___
> 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

Re: [PD] Does Pd have a "sound"?

[Claude Heiland-Allen]

On 14/02/16 22:27, Matti Viljamaa wrote:

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?


Some issues with Pd that affect sound character:

1. cos~ (and osc~) use a small table with linear interpolation, which 
means there is quite a lot of interpolation noise - I wrote about it 
here: http://mathr.co.uk/blog/2015-04-21_approximating_cosine.html


2. vcf~ (and probably other recursive filters) use single precision 
floating point in the feedback loop (pd-double might be different) which 
causes weird rounding artifacts - I wrote about it here: 
http://lists.puredata.info/pipermail/pd-list/2010-08/082104.html


3. cubic interpolation (tabread4~ etc) in Pd uses an (imho) incorrect 
algorithm - it makes a curve that goes through 4 points instead of 
matching the derivatives at the nearest 2 points, which leads to sharp 
corners at the original sample points with associated aliasing artifacts 
- this has been discussed on the lists many times in the past, for 
example here: 
http://lists.puredata.info/pipermail/pd-list/2008-06/062864.html and: 
http://lists.puredata.info/pipermail/pd-list/2010-03/077278.html


4. sig~ (and implicit sig~ from float messages to signal inlets) is 
steppy and only takes effect at block boundaries - compare with .kr in 
SC3 which is (afaik) linearly interpolated between each block boundary


5. Pd doesn't print enough digits to perfectly reconstruct floating 
point values when round-tripping through files, so (eg) biquad~ 
coefficients can become imprecise if you don't write them outside Pd in 
a text editor


6. other systems tend to come bundled with more nice-sounding stuff like 
bandlimited oscillators etc, with Pd you tend to have to find externals 
yourself (deken should make that easier now)



Claude
--
http://mathr.co.uk

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Does Pd have a "sound"?

[Chris McCormick]

On 15/02/16 06:34, Alexandre Torres Porres wrote:

yes it does have a sound, quite similar to Max, but rather distinct from
SuperCollider (this one much "smoother" and "cleaner" or less "harsh"
than the previous ones).

I'm not sure why. Some say about the way SC works internally, with
interpolation or wahtever, but I suspect the objects are coded differently.


Yep, and it is probably also to do with "defaults".

If a particular piece of software or instrument makes it easy to make 
e.g. an aliased square wave, you are probably going to end up with a lot 
of music with aliased square waves, even if it is possible to create 
anti-aliased square waves in the software.


If a particular piece of software makes it easy to generate thousands of 
oscillators, and provides examples for doing so, you are probably going 
to end up with a lot of music with layered oscillators.


If a particular piece of software has cryptography "on" by default, then 
more people are going to encrypt when using it.


Software influences and is influenced by culture. Pd (and other 
software) lends itself to a particular [compositional] culture and the 
code of Pd is in turn influenced by the culture of the people using it. 
I think there probably is a "Pd sound" and if there is then the 
software/culture interface is where it mostly comes from.


Then there are low level things like the treatment of interpolation, 
whether events occur on block boundaries, etc. that give a 
characteristic audio quality, as others described in this thread.


One example just struck me: in Pd it is easier to write patches that you 
can noodle with in a live setting than it is to write patches that 
strongly represent and reify concepts of structured time. As a result a 
lot of Pd work might be best described as "raw" and "live".


Cheers,

Chris.

--
http://mccormick.cx/

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Does Pd have a "sound"?

[Matt Barber]

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" <dmed...@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 <mvilja...@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.b...@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 <mvilja...@kapsi.fi>
>>> To: Pd-List <pd-list@lists.iem.at>
>>> Subject: [PD] Does Pd have a "sound"?
>>> Message-ID: <d9a862c4-2f6e-4bfb-9d7d-b48a0dec5...@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 <anto...@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-livxdyfkvzyzav2e1mh7zn...@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 rest

Re: [PD] Does Pd have a "sound"?

[David Medine]

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 <mvilja...@kapsi.fi 
<mailto:mvilja...@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.b...@gmail.com
<mailto:composer.samuel.b...@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 <mvilja...@kapsi.fi
<mailto:mvilja...@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-b48a0dec5...@kapsi.fi
<mailto:d9a862c4-2f6e-4bfb-9d7d-b48a0dec5...@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 <anto...@metalu.net
<mailto:anto...@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-livxdyfkvzyzav2e1mh7zn...@mail.gmail.com


<mailto:caocg5hwdcssryadkw9mq1qvv-livxdyfkvzyzav2e1mh7zn...@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

[PD] Does Pd have a "sound"?

[Matti Viljamaa]

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



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Does Pd have a "sound"?

[Matti Viljamaa]

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.b...@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 <mvilja...@kapsi.fi <mailto:mvilja...@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-b48a0dec5...@kapsi.fi 
> <mailto:d9a862c4-2f6e-4bfb-9d7d-b48a0dec5...@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 <anto...@metalu.net <mailto:anto...@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-livxdyfkvzyzav2e1mh7zn...@mail.gmail.com 
> <mailto:caocg5hwdcssryadkw9mq1qvv-livxdyfkvzyzav2e1mh7zn...@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 ab

Re: [PD] Does Pd have a "sound"?

[Alexandre Torres Porres]

yes it does have a sound, quite similar to Max, but rather distinct from
SuperCollider (this one much "smoother" and "cleaner" or less "harsh" than
the previous ones).

I'm not sure why. Some say about the way SC works internally, with
interpolation or wahtever, but I suspect the objects are coded differently.

cheers

2016-02-14 20:27 GMT-02:00 Matti Viljamaa :

> 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
>
>
>
> ___
> 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

[PD] Does Pd have a "sound"?

[Samuel Burt]

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 <mvilja...@kapsi.fi>
> To: Pd-List <pd-list@lists.iem.at>
> Subject: [PD] Does Pd have a "sound"?
> Message-ID: <d9a862c4-2f6e-4bfb-9d7d-b48a0dec5...@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 <anto...@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-livxdyfkvzyzav2e1mh7zn...@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 <brbrof...@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 &l