Re: [PD] 0.51-1-test1 issues

[Miller Puckette via Pd-list]

Sure enough - I think I'd better just go back to the buttons.

thanks
M

On Sat, Aug 15, 2020 at 12:09:43AM -0300, Alexandre Torres Porres wrote:
> Em qui., 13 de ago. de 2020 ??s 07:36, Christof Ressi 
> escreveu:
> 
> > now maybe also add 88.2 and 192k?
> >
> > Actually, with very heavy patches that choke up my CPU, sometimes I use
> 22.05k, cause I'm kinda deaf anyway for anything higher than 10k and my
> noise pieces have much more drone/low sounds :)  but I can type that one in
> if it is just too much ;)

> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!UeI-BRK3FOKNhsjkVzPNhmP1NWOOaoN81fHdwhpzg5efGp8YUZm1HUH8GAes$
>  




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

Re: [PD] 0.51-1-test1 issues

[Alexandre Torres Porres]

Em qui., 13 de ago. de 2020 às 07:36, Christof Ressi 
escreveu:

> now maybe also add 88.2 and 192k?
>
> Actually, with very heavy patches that choke up my CPU, sometimes I use
22.05k, cause I'm kinda deaf anyway for anything higher than 10k and my
noise pieces have much more drone/low sounds :)  but I can type that one in
if it is just too much ;)
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Fwd: soundfiler read with offset?

[tim vets]

-- Forwarded message -
Van: tim vets 
Date: za 15 aug. 2020 om 01:56
Subject: Re: [PD] soundfiler read with offset?
To: Christof Ressi 


Thanks for your suggestion,
I haven't tried it out yet, but it looks like a good solution...
Tim

Op do 13 aug. 2020 om 03:38 schreef Christof Ressi :

> Right now this is not possible, but it would be a nice feature. Please
> make a feature request on GitHub!
>
> In the meantime there's a simple (but inefficient) workaround: read the
> soundfile into a different array and then copy it over with [array get] /
> [array set].
>
> Christof
> On 13.08.2020 02:09, tim vets wrote:
>
> Is there a possibility with [soundfiler] to load a sound file into a table
> at an offset?
> Say I want to load one sound into the first half of a table
> and a different one into the second half...?
> Thank you!
> Tim
>
> ___pd-l...@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] recording 192khz

[Miller Puckette via Pd-list]

wierd... maybe it's some form of bus starvation (e.g., USB contention
between USB stick and audio intf) - if this is so you might be able to
record to the SDHC instead, if there's enough space on it.  But I still don't
get why this would happen for Pd and not for jack...

M

On Sat, Aug 15, 2020 at 12:41:27AM +0200, iftah gabbai wrote:
> happens to me all the time :)
> 
> im running pd headless from the command line, at first i used just the
> -audiobuf tag and later i tried specifying the -blocksize (for example 1024
> and higher, went up to 4096 cause i dont care about latency) but for some
> reason it seemed even to make this even worse (i was monitoring the signal
> with adc -> dac)
> 
> 
> 
> 
> 
> 
> On Sat, Aug 15, 2020 at 12:37 AM Miller Puckette  wrote:
> 
> > Oops, sorry I didn't read to the end of your first message :)
> >
> > The remaining difference I can think of between Pd and jack is block
> > size between the app and the audio driver.  I can't imagine that matters,
> > but I've been surprised before.  Have you tried just increasing the
> > blocksize
> > in the suaio dialog?
> >
> > M
> >
> >
> > On Sat, Aug 15, 2020 at 12:20:33AM +0200, iftah gabbai wrote:
> > > thanks miller! im actually writing the files to a usb stick which is def
> > > fast enough for 2x192khz, 24bit, not to the SDHC, so im buffeld. it works
> > > fine if i use jack_capture but somehow not with PD. if this is relevant
> > im
> > > on a fresh install of the latest raspbian OS lite
> > >
> > > cheers
> > >
> > > On Sat, Aug 15, 2020 at 12:00 AM Miller Puckette  wrote:
> > >
> > > > This is almost certainly being limited by write speed to the storage
> > > > medium.  If the file lives on an SDHC card, you can probably improve
> > > > things by getting one that has a higher write speed.  (The
> > specifications
> > > > are very confusing so it might take a while to figure out what kind is
> > how
> > > > fast).
> > > >
> > > > Alternatively, you could attach an ordinary USB disk drive to write
> > > > soundfiles
> > > > to.  Just a regular spinny-disk one; the solid state ones aren't any
> > faster
> > > > because either type is limited by USB bus speed.
> > > >
> > > > cheers
> > > > Miller
> > > >
> > > > On Fri, Aug 14, 2020 at 10:22:26PM +0200, iftah gabbai wrote:
> > > > > hi there, im attempting to record a stereo file (192khz, 24bit) using
> > > > > writesf~ on a rpi3b running headless using the inputs of my usb class
> > > > > compliant soundcard (presonus 24c), so far with no luck,  i get
> > crackles
> > > > > after around 10sec of recordings. the weird thing is that the pd
> > process
> > > > > uses  around 16% of one core - so theoretically it should be fine,
> > > > right? i
> > > > > even tried to up the -audiobuf to 100ms but this does not help
> > either. i
> > > > > write the recordings to an external usb stick that can handle much
> > higher
> > > > > speeds than teh equivalent of 1s/192/24 so i dont think its this
> > either,
> > > > > while i dont run a realtime kernel i have my scaling_governor set to
> > > > > performance. i wonder if anyone have any leads? or is this only
> > possible
> > > > > with rt kernel?
> > > > >
> > > > > best
> > > >
> > > > > ___
> > > > > Pd-list@lists.iem.at mailing list
> > > > > UNSUBSCRIBE and account-management ->
> > > >
> > https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!WY75P-RP7fEB5wWfbvMf9YeFbe3QPmpLN3Ueg1O6sGalKcabQ7HOv3U76Eqw$
> > > >
> > > >
> >
> > > ___
> > > Pd-list@lists.iem.at mailing list
> > > UNSUBSCRIBE and account-management ->
> > https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!RGpNNxBX_Pu7bkn8ly_1PQ9HD2uRrZfYWvRKXfr11LRmHozXMVZoJ4FpyL3f$
> >
> >

> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!W6L8x8W37605JTT2NJ1pUlOH5tYj65d9g1V9Oo53O-jz_3bjUO4-U_bljHoK$
>  




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

Re: [PD] recording 192khz

[iftah gabbai]

happens to me all the time :)

im running pd headless from the command line, at first i used just the
-audiobuf tag and later i tried specifying the -blocksize (for example 1024
and higher, went up to 4096 cause i dont care about latency) but for some
reason it seemed even to make this even worse (i was monitoring the signal
with adc -> dac)






On Sat, Aug 15, 2020 at 12:37 AM Miller Puckette  wrote:

> Oops, sorry I didn't read to the end of your first message :)
>
> The remaining difference I can think of between Pd and jack is block
> size between the app and the audio driver.  I can't imagine that matters,
> but I've been surprised before.  Have you tried just increasing the
> blocksize
> in the suaio dialog?
>
> M
>
>
> On Sat, Aug 15, 2020 at 12:20:33AM +0200, iftah gabbai wrote:
> > thanks miller! im actually writing the files to a usb stick which is def
> > fast enough for 2x192khz, 24bit, not to the SDHC, so im buffeld. it works
> > fine if i use jack_capture but somehow not with PD. if this is relevant
> im
> > on a fresh install of the latest raspbian OS lite
> >
> > cheers
> >
> > On Sat, Aug 15, 2020 at 12:00 AM Miller Puckette  wrote:
> >
> > > This is almost certainly being limited by write speed to the storage
> > > medium.  If the file lives on an SDHC card, you can probably improve
> > > things by getting one that has a higher write speed.  (The
> specifications
> > > are very confusing so it might take a while to figure out what kind is
> how
> > > fast).
> > >
> > > Alternatively, you could attach an ordinary USB disk drive to write
> > > soundfiles
> > > to.  Just a regular spinny-disk one; the solid state ones aren't any
> faster
> > > because either type is limited by USB bus speed.
> > >
> > > cheers
> > > Miller
> > >
> > > On Fri, Aug 14, 2020 at 10:22:26PM +0200, iftah gabbai wrote:
> > > > hi there, im attempting to record a stereo file (192khz, 24bit) using
> > > > writesf~ on a rpi3b running headless using the inputs of my usb class
> > > > compliant soundcard (presonus 24c), so far with no luck,  i get
> crackles
> > > > after around 10sec of recordings. the weird thing is that the pd
> process
> > > > uses  around 16% of one core - so theoretically it should be fine,
> > > right? i
> > > > even tried to up the -audiobuf to 100ms but this does not help
> either. i
> > > > write the recordings to an external usb stick that can handle much
> higher
> > > > speeds than teh equivalent of 1s/192/24 so i dont think its this
> either,
> > > > while i dont run a realtime kernel i have my scaling_governor set to
> > > > performance. i wonder if anyone have any leads? or is this only
> possible
> > > > with rt kernel?
> > > >
> > > > best
> > >
> > > > ___
> > > > Pd-list@lists.iem.at mailing list
> > > > UNSUBSCRIBE and account-management ->
> > >
> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!WY75P-RP7fEB5wWfbvMf9YeFbe3QPmpLN3Ueg1O6sGalKcabQ7HOv3U76Eqw$
> > >
> > >
>
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!RGpNNxBX_Pu7bkn8ly_1PQ9HD2uRrZfYWvRKXfr11LRmHozXMVZoJ4FpyL3f$
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] any way to change the name of delay line used by [vd~] with message?

[Fede Camara Halac]

hi William,

You can use $1 inside clone to name all arrays instead of $0,

so inside your cloned abstraction you'd have:

[vd~ DELAY$1]




fdch.github.io

> On Aug 14, 2020, at 7:25 PM, William Huston  wrote:
> 
> 
> Hi, 
> 
> Is there any way to change the name of the delay line used by [vd~] with a 
> message?
> 
> Alternatively, I think it would be nice for PD to have a mechanism of 
> indirect reference. In this case, 
> 
>[vd~ $0-delay]
> 
> $0-delay refers to the name of the delay line. 
> What I'd like is a way to put a name like DELAY1 inside a variable which I 
> can set and change. So something like 
> 
>  [vd~ ($0-DelayName)] 
> 
> Where $0-DelayName is something I can set to DELAY1. 
> 
> Are either of these possible?
> 
> The reason this has come up, is I'm trying to build an N-band flanger using 
> [clone]. As it stands, it seems like I have to hard-code the name of the 
> delay line read by each instance which is cloned. Since [clone] can only use 
> an abstraction, this means the instances have a different $0 context than the 
> parent patch. 
> 
> So it seems I have to hard-code the name of the delay line used, which means 
> I can have only one of my N-band flangers per patch. That's probably OK, but 
> I would prefer not to use global variable names if possible. 
> 
> Thanks!
> 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
> 
> 
> 
> 
> ___
> 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] recording 192khz

[Miller Puckette via Pd-list]

Oops, sorry I didn't read to the end of your first message :)

The remaining difference I can think of between Pd and jack is block
size between the app and the audio driver.  I can't imagine that matters,
but I've been surprised before.  Have you tried just increasing the blocksize 
in the suaio dialog?

M


On Sat, Aug 15, 2020 at 12:20:33AM +0200, iftah gabbai wrote:
> thanks miller! im actually writing the files to a usb stick which is def
> fast enough for 2x192khz, 24bit, not to the SDHC, so im buffeld. it works
> fine if i use jack_capture but somehow not with PD. if this is relevant im
> on a fresh install of the latest raspbian OS lite
> 
> cheers
> 
> On Sat, Aug 15, 2020 at 12:00 AM Miller Puckette  wrote:
> 
> > This is almost certainly being limited by write speed to the storage
> > medium.  If the file lives on an SDHC card, you can probably improve
> > things by getting one that has a higher write speed.  (The specifications
> > are very confusing so it might take a while to figure out what kind is how
> > fast).
> >
> > Alternatively, you could attach an ordinary USB disk drive to write
> > soundfiles
> > to.  Just a regular spinny-disk one; the solid state ones aren't any faster
> > because either type is limited by USB bus speed.
> >
> > cheers
> > Miller
> >
> > On Fri, Aug 14, 2020 at 10:22:26PM +0200, iftah gabbai wrote:
> > > hi there, im attempting to record a stereo file (192khz, 24bit) using
> > > writesf~ on a rpi3b running headless using the inputs of my usb class
> > > compliant soundcard (presonus 24c), so far with no luck,  i get crackles
> > > after around 10sec of recordings. the weird thing is that the pd process
> > > uses  around 16% of one core - so theoretically it should be fine,
> > right? i
> > > even tried to up the -audiobuf to 100ms but this does not help either. i
> > > write the recordings to an external usb stick that can handle much higher
> > > speeds than teh equivalent of 1s/192/24 so i dont think its this either,
> > > while i dont run a realtime kernel i have my scaling_governor set to
> > > performance. i wonder if anyone have any leads? or is this only possible
> > > with rt kernel?
> > >
> > > best
> >
> > > ___
> > > Pd-list@lists.iem.at mailing list
> > > UNSUBSCRIBE and account-management ->
> > https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!WY75P-RP7fEB5wWfbvMf9YeFbe3QPmpLN3Ueg1O6sGalKcabQ7HOv3U76Eqw$
> >
> >

> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!RGpNNxBX_Pu7bkn8ly_1PQ9HD2uRrZfYWvRKXfr11LRmHozXMVZoJ4FpyL3f$
>  




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

[PD] any way to change the name of delay line used by [vd~] with message?

[William Huston]

Hi,

Is there any way to change the name of the delay line used by [vd~] with a
message?

Alternatively, I think it would be nice for PD to have a mechanism of
indirect reference. In this case,

   [vd~ $0-delay]

$0-delay refers to the name of the delay line.
What I'd like is a way to put a name like DELAY1 inside a variable which I
can set and change. So something like

 [vd~ ($0-DelayName)]

Where $0-DelayName is something I can set to DELAY1.

Are either of these possible?

The reason this has come up, is I'm trying to build an N-band flanger using
[clone]. As it stands, it seems like I have to hard-code the name of the
delay line read by each instance which is cloned. Since [clone] can only
use an abstraction, this means the instances have a different $0 context
than the parent patch.

So it seems I have to hard-code the name of the delay line used, which
means I can have only one of my N-band flangers per patch. That's probably
OK, but I would prefer not to use global variable names if possible.

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

Re: [PD] recording 192khz

[iftah gabbai]

thanks miller! im actually writing the files to a usb stick which is def
fast enough for 2x192khz, 24bit, not to the SDHC, so im buffeld. it works
fine if i use jack_capture but somehow not with PD. if this is relevant im
on a fresh install of the latest raspbian OS lite

cheers

On Sat, Aug 15, 2020 at 12:00 AM Miller Puckette  wrote:

> This is almost certainly being limited by write speed to the storage
> medium.  If the file lives on an SDHC card, you can probably improve
> things by getting one that has a higher write speed.  (The specifications
> are very confusing so it might take a while to figure out what kind is how
> fast).
>
> Alternatively, you could attach an ordinary USB disk drive to write
> soundfiles
> to.  Just a regular spinny-disk one; the solid state ones aren't any faster
> because either type is limited by USB bus speed.
>
> cheers
> Miller
>
> On Fri, Aug 14, 2020 at 10:22:26PM +0200, iftah gabbai wrote:
> > hi there, im attempting to record a stereo file (192khz, 24bit) using
> > writesf~ on a rpi3b running headless using the inputs of my usb class
> > compliant soundcard (presonus 24c), so far with no luck,  i get crackles
> > after around 10sec of recordings. the weird thing is that the pd process
> > uses  around 16% of one core - so theoretically it should be fine,
> right? i
> > even tried to up the -audiobuf to 100ms but this does not help either. i
> > write the recordings to an external usb stick that can handle much higher
> > speeds than teh equivalent of 1s/192/24 so i dont think its this either,
> > while i dont run a realtime kernel i have my scaling_governor set to
> > performance. i wonder if anyone have any leads? or is this only possible
> > with rt kernel?
> >
> > best
>
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!WY75P-RP7fEB5wWfbvMf9YeFbe3QPmpLN3Ueg1O6sGalKcabQ7HOv3U76Eqw$
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] recording 192khz

[Miller Puckette via Pd-list]

This is almost certainly being limited by write speed to the storage
medium.  If the file lives on an SDHC card, you can probably improve
things by getting one that has a higher write speed.  (The specifications
are very confusing so it might take a while to figure out what kind is how
fast).

Alternatively, you could attach an ordinary USB disk drive to write soundfiles
to.  Just a regular spinny-disk one; the solid state ones aren't any faster
because either type is limited by USB bus speed.

cheers
Miller

On Fri, Aug 14, 2020 at 10:22:26PM +0200, iftah gabbai wrote:
> hi there, im attempting to record a stereo file (192khz, 24bit) using
> writesf~ on a rpi3b running headless using the inputs of my usb class
> compliant soundcard (presonus 24c), so far with no luck,  i get crackles
> after around 10sec of recordings. the weird thing is that the pd process
> uses  around 16% of one core - so theoretically it should be fine, right? i
> even tried to up the -audiobuf to 100ms but this does not help either. i
> write the recordings to an external usb stick that can handle much higher
> speeds than teh equivalent of 1s/192/24 so i dont think its this either,
> while i dont run a realtime kernel i have my scaling_governor set to
> performance. i wonder if anyone have any leads? or is this only possible
> with rt kernel?
> 
> best

> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!WY75P-RP7fEB5wWfbvMf9YeFbe3QPmpLN3Ueg1O6sGalKcabQ7HOv3U76Eqw$
>  




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

[PD] recording 192khz

[iftah gabbai]

hi there, im attempting to record a stereo file (192khz, 24bit) using
writesf~ on a rpi3b running headless using the inputs of my usb class
compliant soundcard (presonus 24c), so far with no luck,  i get crackles
after around 10sec of recordings. the weird thing is that the pd process
uses  around 16% of one core - so theoretically it should be fine, right? i
even tried to up the -audiobuf to 100ms but this does not help either. i
write the recordings to an external usb stick that can handle much higher
speeds than teh equivalent of 1s/192/24 so i dont think its this either,
while i dont run a realtime kernel i have my scaling_governor set to
performance. i wonder if anyone have any leads? or is this only possible
with rt kernel?

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