Re: [PD] "good" phasor~ in B16.long-varispeed.pd not looping?

[Philipp Schmalfuß]

Hi Peter,

sure, its on github as well(:
https://github.com/solipd/AudioLab


Quoting "Peter P." :


* Philipp Schmalfuß  [2020-01-07 23:03]:

Hi,

i implemented the B16 example in one of my abstractions "pp.sfplayer~" which
you can download via deken, search for "audiolab".
The onset for tabread4~ is calculated every audio block, so a loop will not
start between blocks but that's good enough for me..

Philipp, this sounds like a very cool abstraction! Can I get it without
downloading (and installing) via Deken as well? Thanks again!



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









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

Re: [PD] "good" phasor~ in B16.long-varispeed.pd not looping?

[Peter P.]

* Philipp Schmalfuß  [2020-01-07 23:03]:
> Hi,
> 
> i implemented the B16 example in one of my abstractions "pp.sfplayer~" which
> you can download via deken, search for "audiolab".
> The onset for tabread4~ is calculated every audio block, so a loop will not
> start between blocks but that's good enough for me..
Philipp, this sounds like a very cool abstraction! Can I get it without
downloading (and installing) via Deken as well? Thanks again!



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

Re: [PD] "good" phasor~ in B16.long-varispeed.pd not looping?

[Philipp Schmalfuß]

Hi,

i implemented the B16 example in one of my abstractions "pp.sfplayer~"  
which you can download via deken, search for "audiolab".
The onset for tabread4~ is calculated every audio block, so a loop  
will not start between blocks but that's good enough for me..



Quoting "Peter P." :


Hi list,

I am trying to understand the B16.long-varispeed.pd patch that measures
a [phasor~]'s phase to calculate an onset which is to be sent into the
right inlet of a [tabread4~]. The patch shows a good example and a bad
one. Interestingly the [phasor~] in the bad one does produce looping
playback, while the onset value in the "good" example keeps increasing
beyond the end of the table. Perhaps this different behavior is intended?

I am currently trying to adapt an abstraction of mine, which uses
[line~] to read a table from a certain start position to an end position
(also backwards) to use the method from the above example. Seems to be
quite a riddle...

P



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










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

Re: [PD] "good" phasor~ in B16.long-varispeed.pd not looping?

[Peter P.]

* Christof Ressi  [2020-01-06 00:37]:
> there's the [tabread4~~] external in zexy which doesn exactly that. The help 
> patch is missing, though. I guess [tabwrite4~] could also do that. Maybe 
> enable it with a flag?
A flag could be avouded if the object would accept signals at the right
inlet by default as messages would be casted to signals automatically
(as you told me a few weeks ago).



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

Re: [PD] "good" phasor~ in B16.long-varispeed.pd not looping?

[Christof Ressi]

> I think it would be super nice if PD could have a 32 bit integer datatype.
 
Double precision Pd gives you 52-bit integer precision out of the box. Some 
scripting languages actually use doubles internally as the only number type, 
e.g. JavaScript, Lua (up to 5.2), 

> Perl has something Larry Wall calls "transmogrification".
> In Perl, there is just a single Scalar data type, which can be internally 
> represented as a string, float, or integer.

This just sounds like a glorified tagged union and I don't think this is much 
different to Pd's atoms. Pd certainly *could* add integers to the set of 
possible atom types, but see below.

> It would probably require a major architecture change.

Yes, and a highly unlikely one :-). If I'm not mistaken, the original Max had 
integers (and recent Max/Msp certainly does), so it has been an intentional 
decision by Miller not to use integers in Pd.

Christof 
 

Gesendet: Montag, 06. Januar 2020 um 00:43 Uhr
Von: "William Huston" 
An: "Sebastian Shader" 
Cc: pd-list 
Betreff: Re: [PD] "good" phasor~ in B16.long-varispeed.pd not looping?

I think it would be super nice if PD could have a 32 bit integer datatype.
(I realize there would be a lot of underlying complexity)
 
Some quantities are naturally reals/floats
(voltages, instantaneous sound pressure levels)
 Other quantities are naturally integers
(counters, memory addresses).
 
IMO trying to force single-precision floats to represent numbers
which the programmer knows will always be integers, is like
banging a square peg into a round hole.
 
A much simpler approach would be to allow for an integer data type.
 
Yes, then you have to solve the problem of how you handle conversions
(connect an integer outlet to a float inlet, etc).
 
It would probably require a major architecture change.
 
I just want to throw this out there...
 
Perl has something Larry Wall calls "transmogrification".
In Perl, there is just a single Scalar data type, which can be
internally represented as a string, float, or integer.
 
The Perl interpreter tries to infer from the context whether
to represent the value as an integer or a float.
 
Just something to consider...
 
BH
 

--
William Huston:  williamahus...@gmail.com[mailto:williamahus...@gmail.com]
Binghamton NY

Public Service Mapping / Videography / Research / Education / Safety Advocacy
Blog[http://WilliamAHuston.blogspot.com] -- 
Facebook[http://facebook.com/billhuston] -- Twitter 
[http://twitter.com/WilliamAHuston] -- 
Youtube[https://www.youtube.com/channel/UCGijK1amWOLglT3YeTyEBNQ?sub_congfirmation=1]
 -- Podcast Blog[https://billhustonpodcast.blogspot.com/]
Document collections: VirtualPipelines[http://TinyURL.com/VirtualPipelines] -- 
BHDCSDimockArchive[http://bit.ly/BHDCSDimockArchive]
Please support my work! -- 
TinyURL.com/DonateToBillHuston[http://TinyURL.com/DonateToBillHuston]
 

  

On Sun, Jan 5, 2020 at 6:29 PM Sebastian Shader via Pd-list 
mailto:pd-list@lists.iem.at]> wrote:
Is the reason that the "offset" inlet isn't a signal inlet mainly for 
performance in most use-cases?
Because if it were it seems like users could give 32-bit floats to both inlets, 
and have them added as doubles internally?

-Seb___
Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]___
 Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]



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

Re: [PD] "good" phasor~ in B16.long-varispeed.pd not looping?

[William Huston]

I think it would be super nice if PD could have a 32 bit integer datatype.
(I realize there would be a lot of underlying complexity)


   - Some quantities are naturally reals/floats
   (voltages, instantaneous sound pressure levels)

   - Other quantities are naturally integers
   (counters, memory addresses).


IMO trying to force single-precision floats to represent numbers
which the programmer knows will always be integers, is like
banging a square peg into a round hole.

A much simpler approach would be to allow for an integer data type.

Yes, then you have to solve the problem of how you handle conversions
(connect an integer outlet to a float inlet, etc).

It would probably require a major architecture change.

I just want to throw this out there...

Perl has something Larry Wall calls "transmogrification".
In Perl, there is just a single Scalar data type, which can be
internally represented as a string, float, or integer.

The Perl interpreter tries to infer from the context whether
to represent the value as an integer or a float.

Just something to consider...

BH

--
William Huston:  williamahus...@gmail.com
Binghamton NY

*Public Service Mapping / Videography / Research / Education / Safety
Advocacy*
Blog  -- Facebook
 -- Twitter
-- Youtube

* -- Podcast Blog *
*Document collections*: VirtualPipelines
 -- BHDCSDimockArchive

*Please support my work! -- *TinyURL.com/DonateToBillHuston





On Sun, Jan 5, 2020 at 6:29 PM Sebastian Shader via Pd-list <
pd-list@lists.iem.at> wrote:

> Is the reason that the "offset" inlet isn't a signal inlet mainly for
> performance in most use-cases?
> Because if it were it seems like users could give 32-bit floats to both
> inlets, and have them added as doubles internally?
>
> -Seb
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] "good" phasor~ in B16.long-varispeed.pd not looping?

[Christof Ressi]

there's the [tabread4~~] external in zexy which doesn exactly that. The help 
patch is missing, though. I guess [tabwrite4~] could also do that. Maybe enable 
it with a flag?
 
Christof
 

Gesendet: Montag, 06. Januar 2020 um 00:08 Uhr
Von: "Sebastian Shader via Pd-list" 
An: pd-l...@iem.at
Betreff: Re: [PD] "good" phasor~ in B16.long-varispeed.pd not looping?

Is the reason that the "offset" inlet isn't a signal inlet mainly for 
performance in most use-cases?
Because if it were it seems like users could give 32-bit floats to both inlets, 
and have them added as doubles internally?

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



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

Re: [PD] "good" phasor~ in B16.long-varispeed.pd not looping?

[Sebastian Shader via Pd-list]

Is the reason that the "offset" inlet isn't a signal inlet mainly for 
performance in most use-cases?Because if it were it seems like users could give 
32-bit floats to both inlets, and have them added as doubles internally?

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

Re: [PD] "good" phasor~ in B16.long-varispeed.pd not looping?

[William Huston]

Adenosina,

I think what I meant to say, is that it seems to me
the particular style of bitcrush which happens
when reading into a large array using [tabread4~],
depending the exact depth into the array, has a nice
crunchy sound I haven't heard replicated using other
methods.

I wish I could have that in an abstraction, where I can dial-in
that sound. Like, the "20 min crush" (reading 20 minutes into
an array at 44.1khz) has a different quality than a "40 minute crush".

I would be neat to have that in a guitar pedal.
Because nobody outside the PD community
would even understand the units. :)

BTW... Off topic...
I been thinking about trying to build a real-time
sound mangler / beat slicer thing... So I've been
studying Katja's Instant Decomposer, and went looking
for an example of the famous Jonny Greenwood
stutter patch... and I found this, a really excellent
virtuoso cover:

https://www.youtube.com/watch?v=kSKozZ5ID9s
(amazing Telecaster tone)

BH





--
William Huston:  williamahus...@gmail.com
Binghamton NY

*Public Service Mapping / Videography / Research / Education / Safety
Advocacy*
Blog  -- Facebook
 -- Twitter
-- Youtube

* -- Podcast Blog *
*Document collections*: VirtualPipelines
 -- BHDCSDimockArchive

*Please support my work! -- *TinyURL.com/DonateToBillHuston





On Sun, Jan 5, 2020 at 10:14 AM Adenosina Tri Phosfato 
wrote:

> Em sáb., 4 de jan. de 2020 às 12:24, William Huston <
> williamahus...@gmail.com> escreveu:
>
>> Funny, I have grown to like the "bitcrush" style distortion
>> from using the existing single-precision method.
>>
>
> but you can do bitcrush and reduce resolution from 64bits as well, right?
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] "good" phasor~ in B16.long-varispeed.pd not looping?

[Gabriel Lecup]

So regarding double precision: is there a way to have long varispeed
without using externals?
I've been banging my head for quite some time, and it seems this is still a
major drawback for casual users like myself ...

On Sun, 5 Jan 2020 at 12:20, William Huston 
wrote:

> As others have stated, 64-bit architecture vs 32 bit, has nothing to do
> with a Single Precision Float vs. Double.
>
> Yes, one can bitcrush from Double also.
>
> On Sun, Jan 5, 2020, 10:14 AM Adenosina Tri Phosfato 
> wrote:
>
>> Em sáb., 4 de jan. de 2020 às 12:24, William Huston <
>> williamahus...@gmail.com> escreveu:
>>
>>> Funny, I have grown to like the "bitcrush" style distortion
>>> from using the existing single-precision method.
>>>
>>
>> but you can do bitcrush and reduce resolution from 64bits as well, right?
>>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] "good" phasor~ in B16.long-varispeed.pd not looping?

[William Huston]

As others have stated, 64-bit architecture vs 32 bit, has nothing to do
with a Single Precision Float vs. Double.

Yes, one can bitcrush from Double also.

On Sun, Jan 5, 2020, 10:14 AM Adenosina Tri Phosfato 
wrote:

> Em sáb., 4 de jan. de 2020 às 12:24, William Huston <
> williamahus...@gmail.com> escreveu:
>
>> Funny, I have grown to like the "bitcrush" style distortion
>> from using the existing single-precision method.
>>
>
> but you can do bitcrush and reduce resolution from 64bits as well, right?
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] "good" phasor~ in B16.long-varispeed.pd not looping?

[Adenosina Tri Phosfato]

Em sáb., 4 de jan. de 2020 às 12:24, William Huston <
williamahus...@gmail.com> escreveu:

> Funny, I have grown to like the "bitcrush" style distortion
> from using the existing single-precision method.
>

but you can do bitcrush and reduce resolution from 64bits as well, right?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] "good" phasor~ in B16.long-varispeed.pd not looping?

[Christof Ressi]

single vs. double precision is not related to 64-bit vs. 32-bit software.

 

BTW, IOhannes already found a way so that single and double precision externals can coexist: https://github.com/pure-data/pure-data/pull/807/commits/8f3397b45b35fa5ec5dab018487554e40a61e369

 

Gesendet: Samstag, 04. Januar 2020 um 20:52 Uhr
Von: "Andrew Lyons" 
An: "Peter P." , "William Huston" , pd-list 
Betreff: Re: [PD] "good" phasor~ in B16.long-varispeed.pd not looping?



 

On Sat, Jan 4, 2020, 9:57 AM Peter P. <peterpar...@fastmail.com> wrote:

> Would be nice if this could be done with perfect backward
> compatibility with existing externals.
It does not make much sense to provide backward compatibility with
externals imho. A solution should be possible using internal objects,
and if such a thing existed, it would make sense to give it a new name
(such as tabread4long~ or whatever



 

We could put all the 32 bit externals in a folder called system32, and then put all the 64-bit externals in a folder called system32. What could possibly go wrong? ;) Seriously though, it's probably better to apply occams razor to this change, and have software that works. 



 



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






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

Re: [PD] "good" phasor~ in B16.long-varispeed.pd not looping?

[Andrew Lyons]

On Sat, Jan 4, 2020, 9:57 AM Peter P.  wrote:

> > Would be nice if this could be done with perfect backward
> > compatibility with existing externals.
> It does not make much sense to provide backward compatibility with
> externals imho. A solution should be possible using internal objects,
> and if such a thing existed, it would make sense to give it a new name
> (such as tabread4long~ or whatever
>

We could put all the 32 bit externals in a folder called system32, and then
put all the 64-bit externals in a folder called system32. What could
possibly go wrong? ;) Seriously though, it's probably better to apply
occams razor to this change, and have software that works.

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

Re: [PD] "good" phasor~ in B16.long-varispeed.pd not looping?

[Peter P.]

* William Huston  [2020-01-04 16:21]:
> I would really love it if someone could provide a sample patch
> demonstrating how to load a long audio file, and be able to scrub
> through it using onset.
> 
> I am utterly baffled by B16.long-varispeed.pd
> 
> Something as simple as Rafael Hernandez' patch here:
> https://www.youtube.com/watch?v=boX0v54SqtU
I am afraid I don't have time to watch an internet video, what does this
patch do? Does it use externals? In what term is it different to
B16.long-varispeed.pd?
 
> Would be nice if this could be done with perfect backward
> compatibility with existing externals.
It does not make much sense to provide backward compatibility with
externals imho. A solution should be possible using internal objects,
and if such a thing existed, it would make sense to give it a new name
(such as tabread4long~ or whatever).



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

Re: [PD] "good" phasor~ in B16.long-varispeed.pd not looping?

[William Huston]

I would really love it if someone could provide a sample patch
demonstrating how to load a long audio file, and be able to scrub
through it using onset.

I am utterly baffled by B16.long-varispeed.pd

Something as simple as Rafael Hernandez' patch here:
https://www.youtube.com/watch?v=boX0v54SqtU

PS: What is the status of PD Double?
I understand it could break a lot of things.

Would be nice if this could be done with perfect backward
compatibility with existing externals.
(Is this naive of me to think this is possible?)

Funny, I have grown to like the "bitcrush" style distortion
from using the existing single-precision method.

But the day I can load a 2 hour .(wav|mp3) file,
and be able to a) scrub through it effortlessly,
and b) be able to identify, store, and manipulate
in/out points down to a per-sample resolution,
I will be in heaven on earth!

BH




--
William Huston:  williamahus...@gmail.com
Binghamton NY

*Public Service Mapping / Videography / Research / Education / Safety
Advocacy*
Blog  -- Facebook
 -- Twitter
-- Youtube

* -- Podcast Blog *
*Document collections*: VirtualPipelines
 -- BHDCSDimockArchive

*Please support my work! -- *TinyURL.com/DonateToBillHuston





On Fri, Jan 3, 2020 at 7:31 PM Miller Puckette  wrote:

> It's not intentional - I must never have checked whether looping worked.
>
> In fact, looping would only work if the begining of the table were copied
> to
> the end (at least 1/10 seconds worth, more if transposing up).  This needs
> updating.
>
> cheers
> M
>
> On Fri, Jan 03, 2020 at 10:50:22PM +0100, Peter P. wrote:
> > Hi list,
> >
> > I am trying to understand the B16.long-varispeed.pd patch that measures
> > a [phasor~]'s phase to calculate an onset which is to be sent into the
> > right inlet of a [tabread4~]. The patch shows a good example and a bad
> > one. Interestingly the [phasor~] in the bad one does produce looping
> > playback, while the onset value in the "good" example keeps increasing
> > beyond the end of the table. Perhaps this different behavior is intended?
> >
> > I am currently trying to adapt an abstraction of mine, which uses
> > [line~] to read a table from a certain start position to an end position
> > (also backwards) to use the method from the above example. Seems to be
> > quite a riddle...
> >
> > P
> >
> >
> >
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] "good" phasor~ in B16.long-varispeed.pd not looping?

[Miller Puckette]

It's not intentional - I must never have checked whether looping worked.

In fact, looping would only work if the begining of the table were copied to
the end (at least 1/10 seconds worth, more if transposing up).  This needs
updating.

cheers
M

On Fri, Jan 03, 2020 at 10:50:22PM +0100, Peter P. wrote:
> Hi list,
> 
> I am trying to understand the B16.long-varispeed.pd patch that measures
> a [phasor~]'s phase to calculate an onset which is to be sent into the
> right inlet of a [tabread4~]. The patch shows a good example and a bad
> one. Interestingly the [phasor~] in the bad one does produce looping
> playback, while the onset value in the "good" example keeps increasing
> beyond the end of the table. Perhaps this different behavior is intended?
> 
> I am currently trying to adapt an abstraction of mine, which uses
> [line~] to read a table from a certain start position to an end position
> (also backwards) to use the method from the above example. Seems to be
> quite a riddle...
> 
> P
> 
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



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