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
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
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: WilliamAHuston@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
On Fri, Jan 3, 2020 at 7:31 PM Miller Puckette msp@ucsd.edu 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
- William Huston williamahuston@gmail.com [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).
On Sat, Jan 4, 2020, 9:57 AM Peter P. peterparker@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.
Em sáb., 4 de jan. de 2020 às 12:24, William Huston < williamahuston@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?
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 porres@gmail.com wrote:
Em sáb., 4 de jan. de 2020 às 12:24, William Huston < williamahuston@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?
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 williamahuston@gmail.com 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 porres@gmail.com wrote:
Em sáb., 4 de jan. de 2020 às 12:24, William Huston < williamahuston@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
Hi,
My pure data patch has grown beyond the processing power of my Raspberry pi. I am looking at software options to make it performant again:
1./ Heavy compiler 2./ Convert abstractions to extensions.
Recommendations? Suggestions?
Thanks
On Sun, Jan 5, 2020, 9:43 AM Gabriel Lecup lecupgabriel@gmail.com wrote:
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 williamahuston@gmail.com 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 porres@gmail.com wrote:
Em sáb., 4 de jan. de 2020 às 12:24, William Huston < williamahuston@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
Hi,
have you tried splitting the workload across several cores, e.g. with [pd~]? This worked quite well for me.
If this isn't possible or not enough, then rewriting parts of your patch as externals can definitely give a significant performance boost. Christof
Gesendet: Sonntag, 05. Januar 2020 um 18:54 Uhr Von: "Andrew Lyons" tstexture@gmail.com An: pd-list pd-list@iem.at Betreff: [PD] How to make a large patch performant
Hi,
My pure data patch has grown beyond the processing power of my Raspberry pi. I am looking at software options to make it performant again: 1./ Heavy compiler 2./ Convert abstractions to extensions. Recommendations? Suggestions? Thanks
Thanks!
[pd~] is news to me. Will research...
Cheers
(Sorry for not trimming)
On Sun, Jan 5, 2020, 10:18 AM Christof Ressi christof.ressi@gmx.at wrote:
Hi,
have you tried splitting the workload across several cores, e.g. with [pd~]? This worked quite well for me.
If this isn't possible or not enough, then rewriting parts of your patch as externals can definitely give a significant performance boost.
Christof
Gesendet: Sonntag, 05. Januar 2020 um 18:54 Uhr Von: "Andrew Lyons" tstexture@gmail.com An: pd-list pd-list@iem.at Betreff: [PD] How to make a large patch performant
Hi,
My pure data patch has grown beyond the processing power of my Raspberry pi. I am looking at software options to make it performant again:
1./ Heavy compiler 2./ Convert abstractions to extensions.
Recommendations? Suggestions?
Thanks
So I'm finding that patches running in pd~ subprocesses cannot read midi input of any kind? Does midi input need to be passed in from the parent patch as audio inputs?
Thanks!
On Sun, Jan 5, 2020, 10:23 AM Andrew Lyons tstexture@gmail.com wrote:
Thanks!
[pd~] is news to me. Will research...
Cheers
(Sorry for not trimming)
On Sun, Jan 5, 2020, 10:18 AM Christof Ressi christof.ressi@gmx.at wrote:
Hi,
have you tried splitting the workload across several cores, e.g. with [pd~]? This worked quite well for me.
If this isn't possible or not enough, then rewriting parts of your patch as externals can definitely give a significant performance boost.
Christof
Gesendet: Sonntag, 05. Januar 2020 um 18:54 Uhr Von: "Andrew Lyons" tstexture@gmail.com An: pd-list pd-list@iem.at Betreff: [PD] How to make a large patch performant
Hi,
My pure data patch has grown beyond the processing power of my Raspberry pi. I am looking at software options to make it performant again:
1./ Heavy compiler 2./ Convert abstractions to extensions.
Recommendations? Suggestions?
Thanks
On 1/6/2020 2:51 AM, Andrew Lyons wrote:
So I'm finding that patches running in pd~ subprocesses cannot read midi input of any kind? Does midi input need to be passed in from the parent patch as audio inputs?
No, why as audio input?
You can pass it as control via the first inlet.
From the [pd~]'s help file:
Any message besides "pd~" is sent to the sub-process. For instance, the
message below sends "bar baz" to any object in the sub-process named
"foo", such as a "receive" object.
~~~
:)
Mensaje telepatico asistido por maquinas.
Ah - Ok. Yep.
Thanks!
============================================= Andrew D Lyons | Tools Developer | http://www.tstex.com =============================================
On Sun, 5 Jan 2020 at 22:19, Lucas Cordiviola lucarda27@hotmail.com wrote:
On 1/6/2020 2:51 AM, Andrew Lyons wrote:
So I'm finding that patches running in pd~ subprocesses cannot read midi input of any kind? Does midi input need to be passed in from the parent patch as audio inputs?
No, why as audio input?
You can pass it as control via the first inlet.
From the [pd~]'s help file:
Any message besides "pd~" is sent to the sub-process. For instance, the message below sends "bar baz" to any object in the sub-process named "foo", such as a "receive" object. ~~~ :) Mensaje telepatico asistido por maquinas.
Do abstractions work in subprocesses? If I put an oscillator in the top level of the sub- process patch, I get audio back, but when I snapshot the output of abstractions (that I know work at the top level) I get nothing but zeros. I have added [PD DSP 1] messages to all abstractions, but still no dice.
Is there another caveat I don't know about?
Thanks
On Sun, Jan 5, 2020, 10:41 PM Andrew Lyons tstexture@gmail.com wrote:
Ah - Ok. Yep.
Thanks!
============================================= Andrew D Lyons | Tools Developer | http://www.tstex.com =============================================
On Sun, 5 Jan 2020 at 22:19, Lucas Cordiviola lucarda27@hotmail.com wrote:
On 1/6/2020 2:51 AM, Andrew Lyons wrote:
So I'm finding that patches running in pd~ subprocesses cannot read midi input of any kind? Does midi input need to be passed in from the parent patch as audio inputs?
No, why as audio input?
You can pass it as control via the first inlet.
From the [pd~]'s help file:
Any message besides "pd~" is sent to the sub-process. For instance, the message below sends "bar baz" to any object in the sub-process named "foo", such as a "receive" object. ~~~ :) Mensaje telepatico asistido por maquinas.
Do abstractions work in subprocesses?
abstractions certainly work in subprocesses.
I have added [PD DSP 1] messages to all abstractions, but still no dice.
also make sure that the *parent* process has DSP running, otherwise time will not advance in the subprocess. Christof
Gesendet: Montag, 06. Januar 2020 um 18:04 Uhr Von: "Andrew Lyons" tstexture@gmail.com An: "Lucas Cordiviola" lucarda27@hotmail.com Cc: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] How to make a large patch performant
Do abstractions work in subprocesses? If I put an oscillator in the top level of the sub- process patch, I get audio back, but when I snapshot the output of abstractions (that I know work at the top level) I get nothing but zeros. I have added [PD DSP 1] messages to all abstractions, but still no dice. Is there another caveat I don't know about? Thanks
On Sun, Jan 5, 2020, 10:41 PM Andrew Lyons <tstexture@gmail.com[mailto:tstexture@gmail.com]> wrote: Ah - Ok. Yep. Thanks!
============================================= Andrew D Lyons | Tools Developer | http://www.tstex.com%5Bhttp://www.tstex.com] =============================================
On Sun, 5 Jan 2020 at 22:19, Lucas Cordiviola <lucarda27@hotmail.com[mailto:lucarda27@hotmail.com]> wrote:On 1/6/2020 2:51 AM, Andrew Lyons wrote:
So I'm finding that patches running in pd~ subprocesses cannot read midi input of any kind? Does midi input need to be passed in from the parent patch as audio inputs?
No, why as audio input?
You can pass it as control via the first inlet.
From the [pd~]'s help file:
Any message besides "pd~" is sent to the sub-process. For instance, the
message below sends "bar baz" to any object in the sub-process named
"foo", such as a "receive" object.
~~~
:)
Mensaje telepatico asistido por maquinas.
_______________________________________________ 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]
Gabriel Lecup wrote:
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 ...
Hi,
something in-between comes along ... slightly off-topic since it doedsn't touch the "B16.long-varispeed.pd" discussion but only your last question:
i built an abstraction called [ol_sfplay~] that does varispeed of .wav files of any length, because it actually loads small chunks of a given audio file into tables and plays them back with several [tabread4~]s and small overlapping crossfades.
the cool thing about it is that the .wav file can have any length you like, since it is not completely loaded into RAM
drawbacks:
1.) needs externals (iemlib, zexy, iemguts) 2.) .wav only 3.) pitch changing (varispeed) is not as smooth as it would be in a purely array-read mechanism, so you will hear the "steps" of the window-size.
still, i hope it provides something useful for your needs ...
best
oliver
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: WilliamAHuston@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
On Sun, Jan 5, 2020 at 10:14 AM Adenosina Tri Phosfato porres@gmail.com wrote:
Em sáb., 4 de jan. de 2020 às 12:24, William Huston < williamahuston@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?
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." peterparker@fastmail.com:
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
- Philipp Schmalfuß philipp.schmalfuss@uni-weimar.de [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!
Hi Peter,
sure, its on github as well(: https://github.com/solipd/AudioLab
Quoting "Peter P." peterparker@fastmail.com:
- Philipp Schmalfuß philipp.schmalfuss@uni-weimar.de [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
-
Adenosina Tri Phosfato -
Andrew Lyons -
Christof Ressi -
Gabriel Lecup -
Lucas Cordiviola -
Miller Puckette -
oliver -
Peter P. -
Philipp Schmalfuß -
William Huston