Re: [PD] [sfinfo~]

[Dan Wilcox]

Ok, here is a fix. Please test: 
https://github.com/pure-data/pure-data/pull/1566 


> On Jan 28, 2022, at 11:04 PM, Dan Wilcox  wrote:
> 
> It's a bug, the failure is here: 
> https://github.com/pure-data/pure-data/blob/master/src/d_soundfile.c#L1307 
> 
> 
> The intent as previously stated is that not supplying a table name should use 
> the value read from the header. However, for raw files there is no header so 
> we *have* to try reading the length of the file. This logic is not working 
> and I will try to fix it now.
> 
> Previously, I had a an "info" message which did this separately from "read" 
> when I was overhauling sound file handling, but Miller's suggestion to check 
> for the array name was more elegant.
> 
>> On Jan 28, 2022, at 9:55 PM, pd-list-requ...@lists.iem.at 
>>  wrote:
>> 
>> Message: 3
>> Date: Fri, 28 Jan 2022 20:55:43 +
>> From: Pierre Alexandre Tremblay > >
>> To: Lucas Cordiviola mailto:lucard...@hotmail.com>>
>> Cc: pd-list@lists.iem.at 
>> Subject: Re: [PD] [sfinfo~]
>> Message-ID: > >
>> Content-Type: text/plain; charset="utf-8"
>> 
>> In d_soundfile.c around line 1207 we could see if there is only 1 arg left 
>> as a else if. If that?s the case, we could just bail down to done: and bob?s 
>> your uncle...
> 
> 
> Dan Wilcox
> @danomatika 
> danomatika.com 
> robotcowboy.com 
> 
> 
> 


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



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

Re: [PD] [sfinfo~]

[Dan Wilcox]

It's a bug, the failure is here: 
https://github.com/pure-data/pure-data/blob/master/src/d_soundfile.c#L1307 


The intent as previously stated is that not supplying a table name should use 
the value read from the header. However, for raw files there is no header so we 
*have* to try reading the length of the file. This logic is not working and I 
will try to fix it now.

Previously, I had a an "info" message which did this separately from "read" 
when I was overhauling sound file handling, but Miller's suggestion to check 
for the array name was more elegant.

> On Jan 28, 2022, at 9:55 PM, pd-list-requ...@lists.iem.at wrote:
> 
> Message: 3
> Date: Fri, 28 Jan 2022 20:55:43 +
> From: Pierre Alexandre Tremblay  >
> To: Lucas Cordiviola mailto:lucard...@hotmail.com>>
> Cc: pd-list@lists.iem.at 
> Subject: Re: [PD] [sfinfo~]
> Message-ID:  >
> Content-Type: text/plain; charset="utf-8"
> 
> In d_soundfile.c around line 1207 we could see if there is only 1 arg left as 
> a else if. If that?s the case, we could just bail down to done: and bob?s 
> your uncle...


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



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

Re: [PD] [sfinfo~]

[Pierre Alexandre Tremblay]

In d_soundfile.c around line 1207 we could see if there is only 1 arg left as a 
else if. If that’s the case, we could just bail down to done: and bob’s your 
uncle...


> On 28 Jan 2022, at 20:30, Lucas Cordiviola  wrote:
> 
> @Oliver
> 
> The only problem I know with [soundfile_info] is that it counts as samples 
> any metadata in the file. Is not common to find metadata in wav files but 
> there might be some.
> 
> It would be really nice if [soundfiler] just extracts n of samples only by 
> reading the header.
> 
> @Dan:
> 
> Oliver's patch shows that [soundfiler] does not just "read the header".
> 
> 
> 
> --
> 
> Mensaje telepatico asistido por maquinas.
> 
> On 1/28/2022 5:19 PM, Dan Wilcox wrote:
>> Don't pass an array name when calling open and it reports the info without 
>> reading any samples, ie. just reads the header info then closes the file.
>> 
>>> On Jan 28, 2022, at 8:37 PM, pd-list-requ...@lists.iem.at wrote:
>>> 
>>> Message: 1
>>> Date: Fri, 28 Jan 2022 20:29:44 +0100
>>> From: oliver 
>>> Cc: Pd-List 
>>> Subject: Re: [PD] [sfinfo~]
>>> Message-ID: <32ea001b-5109-cb72-2397-cb820d930...@klingt.org>
>>> Content-Type: text/plain; charset=UTF-8; format=flowed
>>> 
>>> Miller Puckette via Pd-list wrote:
 Hi PA -
 
 Are you doing stuff that "soundfiler" doesn't?  If so, it would be better
 to add to the soundfiler object than to add a new object with its own name.
>>> 
>>> The one thing that [soundfiler] can not do, is to report the length of a
>>> soundfile WITHOUT fully loading it into an array.
>>> 
>>> That would be a great feature to have for [soundfiler]'s right outlet,
>>> especially in the case of big files.
>>> 
>>> You can get all the other information (channels, samplerate etc.) by
>>> loading just a small sniplet of the source file (even 1 sample is
>>> sufficient IIRC) into a buffer, but not the length. you would need to
>>> add "-resize" to the load flags, which is not useful for (very) long files
>>> 
>>> i still use IEMLIB's [soundfile_info] for that purpose.
>>> 
>>> 
>>> 
>>> best
>>> 
>>> oliver
>> 
>> 
>> Dan Wilcox
>> @danomatika 
>> danomatika.com 
>> robotcowboy.com 
>> 
>> 
>> 
>> 
>> ___
>> 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



smime.p7s
Description: S/MIME cryptographic signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [sfinfo~]

[Lucas Cordiviola]

@Oliver

The only problem I know with [soundfile_info] is that it counts as 
samples any metadata in the file. Is not common to find metadata in wav 
files but there might be some.


It would be really nice if [soundfiler] just extracts n of samples only 
by reading the header.


@Dan:

Oliver's patch shows that [soundfiler] does not just "read the header".



--

Mensaje telepatico asistido por maquinas.

On 1/28/2022 5:19 PM, Dan Wilcox wrote:
Don't pass an array name when calling open and it reports the info 
without reading any samples, ie. just reads the header info then 
closes the file.



On Jan 28, 2022, at 8:37 PM, pd-list-requ...@lists.iem.at wrote:

Message: 1
Date: Fri, 28 Jan 2022 20:29:44 +0100
From: oliver 
Cc: Pd-List 
Subject: Re: [PD] [sfinfo~]
Message-ID: <32ea001b-5109-cb72-2397-cb820d930...@klingt.org>
Content-Type: text/plain; charset=UTF-8; format=flowed

Miller Puckette via Pd-list wrote:

Hi PA -

Are you doing stuff that "soundfiler" doesn't?  If so, it would be 
better
to add to the soundfiler object than to add a new object with its 
own name.


The one thing that [soundfiler] can not do, is to report the length of a
soundfile WITHOUT fully loading it into an array.

That would be a great feature to have for [soundfiler]'s right outlet,
especially in the case of big files.

You can get all the other information (channels, samplerate etc.) by
loading just a small sniplet of the source file (even 1 sample is
sufficient IIRC) into a buffer, but not the length. you would need to
add "-resize" to the load flags, which is not useful for (very) long 
files


i still use IEMLIB's [soundfile_info] for that purpose.



best

oliver



Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 




___
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] [sfinfo~]

[Alexandre Torres Porres]

I chose a small file and could see how soundfile_info is faster (btw, why
are you using -stdlib?)

So, shall we open a feature request on github?

Em sex., 28 de jan. de 2022 às 17:05, oliver  escreveu:

> Miller Puckette via Pd-list wrote:
> > Excellent - nothing to do then.  My favorite kind of dolist.
>
>
> Well, not quite ...
>
> Lucas' method of using [soundfiler] to get a (really long) soundfile's
> length still loads the complete file into RAM, as it would into an
> array. (i'm talking a 60 minute long audio file here)
>
> This has 3 drawbacks:
>
> 1.) audio dropout while loading, depending on the file's length
> 2.) can use huge amounts of RAM
> 3.) takes much longer than [soundfile_info]
>
> attached is an example patch that illustrates both approaches.
>
> (use the same long soundfile for each method to see what i mean)
>
>
>
> then again: since i use IEMLIB regularly it's not that much of a hassle.
> it's just not plain vanilla, that's all ...
>
>
> best
>
> oliver
> ___
> 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] [sfinfo~]

[Dan Wilcox]

Ah, sorry, I meant "read" not "open." If calling read without an array takes 
the same amount of time as reading into an array, please open a bug report.

> On Jan 28, 2022, at 9:19 PM, Dan Wilcox  wrote:
> 
> Don't pass an array name when calling open and it reports the info without 
> reading any samples, ie. just reads the header info then closes the file.
> 
>> On Jan 28, 2022, at 8:37 PM, pd-list-requ...@lists.iem.at 
>>  wrote:
>> 
>> Message: 1
>> Date: Fri, 28 Jan 2022 20:29:44 +0100
>> From: oliver mailto:oli...@klingt.org>>
>> Cc: Pd-List mailto:pd-list@lists.iem.at>>
>> Subject: Re: [PD] [sfinfo~]
>> Message-ID: <32ea001b-5109-cb72-2397-cb820d930...@klingt.org 
>> >
>> Content-Type: text/plain; charset=UTF-8; format=flowed
>> 
>> Miller Puckette via Pd-list wrote:
>>> Hi PA -
>>> 
>>> Are you doing stuff that "soundfiler" doesn't?  If so, it would be better
>>> to add to the soundfiler object than to add a new object with its own name.
>> 
>> The one thing that [soundfiler] can not do, is to report the length of a 
>> soundfile WITHOUT fully loading it into an array.
>> 
>> That would be a great feature to have for [soundfiler]'s right outlet, 
>> especially in the case of big files.
>> 
>> You can get all the other information (channels, samplerate etc.) by 
>> loading just a small sniplet of the source file (even 1 sample is 
>> sufficient IIRC) into a buffer, but not the length. you would need to 
>> add "-resize" to the load flags, which is not useful for (very) long files
>> 
>> i still use IEMLIB's [soundfile_info] for that purpose.
>> 
>> 
>> 
>> best
>> 
>> oliver
> 
> 
> Dan Wilcox
> @danomatika 
> danomatika.com 
> robotcowboy.com 
> 
> 
> 


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



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

Re: [PD] [sfinfo~]

[Miller Puckette via Pd-list]

Yep, I can think of other reasons you'd want to know the size of a soundfile
in a Pd patch without having to read the whole thing in.

cheers
M

On Fri, Jan 28, 2022 at 07:32:02PM +, Pierre Alexandre Tremblay wrote:
> > I forgot is even simpler (no need for an array)
> 
> Oh la la this is embarrassing. I didn’t know one could not supply an array… 
> but that way I don’t get the size of the file in frames.
> 
> > Are you doing stuff that "soundfiler" doesn't?  If so, it would be better 
> > to add to the soundfiler object than to add a new object with its own name.
> 
> 
> Indeed Miller I’ll do a PR to add it at the end then. I get everything else 
> with soundfiler
> 
> For info, I need the size of the sum of my sound files in frames and in 
> channels to allocate the right size once. I do that in Max and SC doing 2 
> passes, once to read the headers and accumulate what I need in both 
> dimensions (and capture the SR at the same time) then I assign then I read 
> and copy. For large corpora, this is useful.
> 
> So the proposal is not so big and bold as my first email… but still a needed 
> feature.



> ___
> 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] [sfinfo~]

[Dan Wilcox]

Don't pass an array name when calling open and it reports the info without 
reading any samples, ie. just reads the header info then closes the file.

> On Jan 28, 2022, at 8:37 PM, pd-list-requ...@lists.iem.at wrote:
> 
> Message: 1
> Date: Fri, 28 Jan 2022 20:29:44 +0100
> From: oliver mailto:oli...@klingt.org>>
> Cc: Pd-List mailto:pd-list@lists.iem.at>>
> Subject: Re: [PD] [sfinfo~]
> Message-ID: <32ea001b-5109-cb72-2397-cb820d930...@klingt.org 
> >
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> Miller Puckette via Pd-list wrote:
>> Hi PA -
>> 
>> Are you doing stuff that "soundfiler" doesn't?  If so, it would be better
>> to add to the soundfiler object than to add a new object with its own name.
> 
> The one thing that [soundfiler] can not do, is to report the length of a 
> soundfile WITHOUT fully loading it into an array.
> 
> That would be a great feature to have for [soundfiler]'s right outlet, 
> especially in the case of big files.
> 
> You can get all the other information (channels, samplerate etc.) by 
> loading just a small sniplet of the source file (even 1 sample is 
> sufficient IIRC) into a buffer, but not the length. you would need to 
> add "-resize" to the load flags, which is not useful for (very) long files
> 
> i still use IEMLIB's [soundfile_info] for that purpose.
> 
> 
> 
> best
> 
> oliver


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



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

Re: [PD] [sfinfo~]

[oliver]

Miller Puckette via Pd-list wrote:

Excellent - nothing to do then.  My favorite kind of dolist.



Well, not quite ...

Lucas' method of using [soundfiler] to get a (really long) soundfile's 
length still loads the complete file into RAM, as it would into an 
array. (i'm talking a 60 minute long audio file here)


This has 3 drawbacks:

1.) audio dropout while loading, depending on the file's length
2.) can use huge amounts of RAM
3.) takes much longer than [soundfile_info]

attached is an example patch that illustrates both approaches.

(use the same long soundfile for each method to see what i mean)



then again: since i use IEMLIB regularly it's not that much of a hassle. 
it's just not plain vanilla, that's all ...



best

oliver
#N canvas 806 80 350 355 10;
#X declare -stdlib iemlib;
#X obj 47 227 soundfiler;
#X msg 196 205 read \$1;
#X obj 196 161 openpanel;
#X obj 196 138 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
-1 -1;
#X obj 19 16 declare -stdlib iemlib;
#X obj 196 229 soundfile_info;
#X obj 47 248 print A;
#X obj 196 250 print B;
#X obj 196 182 t s b;
#X obj 281 14 osc~ 440;
#X obj 281 35 *~ 0.2;
#X obj 269 92 dac~;
#X msg 47 205 read \$1;
#X obj 47 161 openpanel;
#X obj 47 139 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X obj 47 182 t s b;
#X text 45 104 select a long soundfile;
#X obj 74 297 realtime;
#X msg 119 276 bang;
#X floatatom 74 318 0 0 0 0 - - -;
#X obj 223 297 realtime;
#X msg 268 276 bang;
#X floatatom 223 318 0 0 0 0 - - -;
#X obj 281 67 *~ 0;
#X obj 253 37 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X text 68 137 A: ARRAY METHOD;
#X text 214 137 A: WITH IEMLIB;
#X text 195 15 also note audio drop-out, f 11;
#X connect 0 0 6 0;
#X connect 0 0 18 0;
#X connect 1 0 5 0;
#X connect 2 0 8 0;
#X connect 3 0 2 0;
#X connect 5 0 7 0;
#X connect 5 0 21 0;
#X connect 8 0 1 0;
#X connect 8 1 20 0;
#X connect 9 0 10 0;
#X connect 10 0 23 0;
#X connect 12 0 0 0;
#X connect 13 0 15 0;
#X connect 14 0 13 0;
#X connect 15 0 12 0;
#X connect 15 1 17 0;
#X connect 17 0 19 0;
#X connect 18 0 17 1;
#X connect 20 0 22 0;
#X connect 21 0 20 1;
#X connect 23 0 11 0;
#X connect 23 0 11 1;
#X connect 24 0 23 1;
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [sfinfo~]

[Miller Puckette via Pd-list]

Excellent - nothing to do then.  My favorite kind of dolist.

cheers
M

On Fri, Jan 28, 2022 at 07:37:04PM +, Pierre Alexandre Tremblay wrote:
> Wait - this is embarrassing, it seems that the left outlet still spits out 
> the number of samples when there are no destination arrays so I should be 
> golden…
> 
> I probably need a weekend. Sorry for the Friday night noise.
> 
> > On 28 Jan 2022, at 19:35, Miller Puckette  wrote:
> > 
> > Yep, I can think of other reasons you'd want to know the size of a soundfile
> > in a Pd patch without having to read the whole thing in.
> > 
> > cheers
> > M
> > 
> > On Fri, Jan 28, 2022 at 07:32:02PM +, Pierre Alexandre Tremblay wrote:
> >>> I forgot is even simpler (no need for an array)
> >> 
> >> Oh la la this is embarrassing. I didn’t know one could not supply an 
> >> array… but that way I don’t get the size of the file in frames.
> >> 
> >>> Are you doing stuff that "soundfiler" doesn't?  If so, it would be better 
> >>> to add to the soundfiler object than to add a new object with its own 
> >>> name.
> >> 
> >> 
> >> Indeed Miller I’ll do a PR to add it at the end then. I get everything 
> >> else with soundfiler
> >> 
> >> For info, I need the size of the sum of my sound files in frames and in 
> >> channels to allocate the right size once. I do that in Max and SC doing 2 
> >> passes, once to read the headers and accumulate what I need in both 
> >> dimensions (and capture the SR at the same time) then I assign then I read 
> >> and copy. For large corpora, this is useful.
> >> 
> >> So the proposal is not so big and bold as my first email… but still a 
> >> needed feature.
> > 
> > 
> > 
> >> ___
> >> 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] [sfinfo~]

[Pierre Alexandre Tremblay]

Wait - this is embarrassing, it seems that the left outlet still spits out the 
number of samples when there are no destination arrays so I should be golden…

I probably need a weekend. Sorry for the Friday night noise.

> On 28 Jan 2022, at 19:35, Miller Puckette  wrote:
> 
> Yep, I can think of other reasons you'd want to know the size of a soundfile
> in a Pd patch without having to read the whole thing in.
> 
> cheers
> M
> 
> On Fri, Jan 28, 2022 at 07:32:02PM +, Pierre Alexandre Tremblay wrote:
>>> I forgot is even simpler (no need for an array)
>> 
>> Oh la la this is embarrassing. I didn’t know one could not supply an array… 
>> but that way I don’t get the size of the file in frames.
>> 
>>> Are you doing stuff that "soundfiler" doesn't?  If so, it would be better 
>>> to add to the soundfiler object than to add a new object with its own name.
>> 
>> 
>> Indeed Miller I’ll do a PR to add it at the end then. I get everything else 
>> with soundfiler
>> 
>> For info, I need the size of the sum of my sound files in frames and in 
>> channels to allocate the right size once. I do that in Max and SC doing 2 
>> passes, once to read the headers and accumulate what I need in both 
>> dimensions (and capture the SR at the same time) then I assign then I read 
>> and copy. For large corpora, this is useful.
>> 
>> So the proposal is not so big and bold as my first email… but still a needed 
>> feature.
> 
> 
> 
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list
> 



smime.p7s
Description: S/MIME cryptographic signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [sfinfo~]

[Pierre Alexandre Tremblay]

Email crossing, I literally apologised for my dumbness and noticed that single 
difference - we’re on the same page here :)

> On 28 Jan 2022, at 19:29, oliver  wrote:
> 
> Miller Puckette via Pd-list wrote:
>> Hi PA -
>> Are you doing stuff that "soundfiler" doesn't?  If so, it would be better
>> to add to the soundfiler object than to add a new object with its own name.
> 
> The one thing that [soundfiler] can not do, is to report the length of a 
> soundfile WITHOUT fully loading it into an array.
> 
> That would be a great feature to have for [soundfiler]'s right outlet, 
> especially in the case of big files.
> 
> You can get all the other information (channels, samplerate etc.) by loading 
> just a small sniplet of the source file (even 1 sample is sufficient IIRC) 
> into a buffer, but not the length. you would need to add "-resize" to the 
> load flags, which is not useful for (very) long files
> 
> i still use IEMLIB's [soundfile_info] for that purpose.
> 
> 
> 
> best
> 
> oliver
> 
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



smime.p7s
Description: S/MIME cryptographic signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [sfinfo~]

[Pierre Alexandre Tremblay]

> I forgot is even simpler (no need for an array)

Oh la la this is embarrassing. I didn’t know one could not supply an array… but 
that way I don’t get the size of the file in frames.

> Are you doing stuff that "soundfiler" doesn't?  If so, it would be better to 
> add to the soundfiler object than to add a new object with its own name.


Indeed Miller I’ll do a PR to add it at the end then. I get everything else 
with soundfiler

For info, I need the size of the sum of my sound files in frames and in 
channels to allocate the right size once. I do that in Max and SC doing 2 
passes, once to read the headers and accumulate what I need in both dimensions 
(and capture the SR at the same time) then I assign then I read and copy. For 
large corpora, this is useful.

So the proposal is not so big and bold as my first email… but still a needed 
feature.

smime.p7s
Description: S/MIME cryptographic signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [sfinfo~]

[oliver]

Miller Puckette via Pd-list wrote:

Hi PA -

Are you doing stuff that "soundfiler" doesn't?  If so, it would be better
to add to the soundfiler object than to add a new object with its own name.


The one thing that [soundfiler] can not do, is to report the length of a 
soundfile WITHOUT fully loading it into an array.


That would be a great feature to have for [soundfiler]'s right outlet, 
especially in the case of big files.


You can get all the other information (channels, samplerate etc.) by 
loading just a small sniplet of the source file (even 1 sample is 
sufficient IIRC) into a buffer, but not the length. you would need to 
add "-resize" to the load flags, which is not useful for (very) long files


i still use IEMLIB's [soundfile_info] for that purpose.



best

oliver



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

Re: [PD] [sfinfo~]

[Lucas Cordiviola]

You can get that info with [soundfiler]


  [array define myarray]

  [foo.wav(
  |
  [read -resize $1 myarray(
  |
  |
  [soundfiler]
  |  |
  |  [print stuff]
  |
  [print n of samples]


--

Mensaje telepatico asistido por maquinas.

On 1/28/2022 3:31 PM, Miller Puckette via Pd-list wrote:

Hi PA -

Are you doing stuff that "soundfiler" doesn't?  If so, it would be better
to add to the soundfiler object than to add a new object with its own name.

cheers
Miller

On Fri, Jan 28, 2022 at 06:17:21PM +, Pierre Alexandre Tremblay wrote:

Hello again

So I was missing an object that is quite useful when dealing with audio files 
in batches. Attached is the ugly file in progress to read (with [file]) the 
header of audio files and demingle it to get the number of channels and number 
of frames and sampling rate… what the Max object [sfinfo~] does.

Now I notices that the pd API offers me the headers to recode it in C - so I 
have 2 options here

- I don’t bother anyone and I coder it as fluid.sfinfo
- I code it as [sfinfo~] and make a PR and pray that the dev gods pick on it 
and in the meantime I just include my PR version.

I looked in decken and couldn’t find that string (soundfile, sound file, etc) 
so I’m pretty sure it is not there.

In all cases this is a very useful object to have. I offer my pd attempt in 
sacrifice to the people who want to have a laugh. It kind of works… but that 
‘extended’ format (80 bit float anyone?) is a pain to detangle :)







___
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] [sfinfo~]

[Lucas Cordiviola]

I forgot is even simpler (no need for an array)


  [read foo.wav(
  |
  [soundfiler]
  |  |
  |  [print stuff]
  |
  [print n of samples]


--

Mensaje telepatico asistido por maquinas.

On 1/28/2022 3:36 PM, Lucas Cordiviola wrote:

You can get that info with [soundfiler]


  [array define myarray]

  [foo.wav(
  |
  [read -resize $1 myarray(
  |
  |
  [soundfiler]
  |  |
  |  [print stuff]
  |
  [print n of samples]


--

Mensaje telepatico asistido por maquinas.

On 1/28/2022 3:31 PM, Miller Puckette via Pd-list wrote:

Hi PA -

Are you doing stuff that "soundfiler" doesn't?  If so, it would be 
better
to add to the soundfiler object than to add a new object with its own 
name.


cheers
Miller

On Fri, Jan 28, 2022 at 06:17:21PM +, Pierre Alexandre Tremblay 
wrote:

Hello again

So I was missing an object that is quite useful when dealing with 
audio files in batches. Attached is the ugly file in progress to 
read (with [file]) the header of audio files and demingle it to get 
the number of channels and number of frames and sampling rate… what 
the Max object [sfinfo~] does.


Now I notices that the pd API offers me the headers to recode it in 
C - so I have 2 options here


- I don’t bother anyone and I coder it as fluid.sfinfo
- I code it as [sfinfo~] and make a PR and pray that the dev gods 
pick on it and in the meantime I just include my PR version.


I looked in decken and couldn’t find that string (soundfile, sound 
file, etc) so I’m pretty sure it is not there.


In all cases this is a very useful object to have. I offer my pd 
attempt in sacrifice to the people who want to have a laugh. It kind 
of works… but that ‘extended’ format (80 bit float anyone?) is a 
pain to detangle :)








___
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] [sfinfo~]

[William Brent]

If you're after the number of channels and sampling rate, the list coming
out of the right outlet of [soundfiler] gives you that. And the left outlet
gives you the number of frames/samples, but beware that it actually reports
the number of samples loaded to the target array. So if you don't use the
-resize flag it won't necessarily report the number of samples in the file.

On Fri, Jan 28, 2022 at 1:19 PM Pierre Alexandre Tremblay <
tremb...@gmail.com> wrote:

> Hello again
>
> So I was missing an object that is quite useful when dealing with audio
> files in batches. Attached is the ugly file in progress to read (with
> [file]) the header of audio files and demingle it to get the number of
> channels and number of frames and sampling rate… what the Max object
> [sfinfo~] does.
>
> Now I notices that the pd API offers me the headers to recode it in C - so
> I have 2 options here
>
> - I don’t bother anyone and I coder it as fluid.sfinfo
> - I code it as [sfinfo~] and make a PR and pray that the dev gods pick on
> it and in the meantime I just include my PR version.
>
> I looked in decken and couldn’t find that string (soundfile, sound file,
> etc) so I’m pretty sure it is not there.
>
> In all cases this is a very useful object to have. I offer my pd attempt
> in sacrifice to the people who want to have a laugh. It kind of works… but
> that ‘extended’ format (80 bit float anyone?) is a pain to detangle :)
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>


-- 
William Brent

“Great minds flock together”
Conflations: conversational idiom for the 21st century

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

Re: [PD] [sfinfo~]

[Miller Puckette via Pd-list]

Hi PA -

Are you doing stuff that "soundfiler" doesn't?  If so, it would be better
to add to the soundfiler object than to add a new object with its own name.

cheers
Miller

On Fri, Jan 28, 2022 at 06:17:21PM +, Pierre Alexandre Tremblay wrote:
> Hello again
> 
> So I was missing an object that is quite useful when dealing with audio files 
> in batches. Attached is the ugly file in progress to read (with [file]) the 
> header of audio files and demingle it to get the number of channels and 
> number of frames and sampling rate… what the Max object [sfinfo~] does.
> 
> Now I notices that the pd API offers me the headers to recode it in C - so I 
> have 2 options here
> 
> - I don’t bother anyone and I coder it as fluid.sfinfo
> - I code it as [sfinfo~] and make a PR and pray that the dev gods pick on it 
> and in the meantime I just include my PR version.
> 
> I looked in decken and couldn’t find that string (soundfile, sound file, etc) 
> so I’m pretty sure it is not there.
> 
> In all cases this is a very useful object to have. I offer my pd attempt in 
> sacrifice to the people who want to have a laugh. It kind of works… but that 
> ‘extended’ format (80 bit float anyone?) is a pain to detangle :)
> 





> ___
> 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] [sfinfo~]

[Pierre Alexandre Tremblay]

Hello again

So I was missing an object that is quite useful when dealing with audio files 
in batches. Attached is the ugly file in progress to read (with [file]) the 
header of audio files and demingle it to get the number of channels and number 
of frames and sampling rate… what the Max object [sfinfo~] does.

Now I notices that the pd API offers me the headers to recode it in C - so I 
have 2 options here

- I don’t bother anyone and I coder it as fluid.sfinfo
- I code it as [sfinfo~] and make a PR and pray that the dev gods pick on it 
and in the meantime I just include my PR version.

I looked in decken and couldn’t find that string (soundfile, sound file, etc) 
so I’m pretty sure it is not there.

In all cases this is a very useful object to have. I offer my pd attempt in 
sacrifice to the people who want to have a laugh. It kind of works… but that 
‘extended’ format (80 bit float anyone?) is a pain to detangle :)



header-parsing.pd
Description: Binary data


smime.p7s
Description: S/MIME cryptographic signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] A quick question - a bug or me?

[Dan Wilcox]

You can set the font using -font-family on the command line. Also, I wouldn’t 
take that approach as Pd packages on Linux distros *should* have DejaVu Sans 
Mono as a dependency. If they don’t, the problem lies with the packaging and 
not with Pd.

enohp ym morf tnes
---
Dan Wilcox
danomatika.com
robotcowboy.com


> On Jan 28, 2022, at 3:04 PM, Pierre Alexandre Tremblay  
> wrote:
> 
> Oh this is good - now I presume many other patches one someone’s machine 
> will look awful if their Linux doesn’t find the font, so I shouldn’t feel too 
> bad. I’ll make sure they look decent with what I can expect from v0.48
> 
> Thanks!
> 
>> On 28 Jan 2022, at 13:32, Dan Wilcox  wrote:
>> 
>> Check the actual font used by setting Log level 4 All and compare "detected 
>> font" with "using font." On Linux, Pd doesn't include the font itself, so it 
>> relies on DVSM being installed to the system and Tk finding it when the GUI 
>> opens. If it can't find DVSM, it reverts to a series of backup fonts 
>> starting with the old default of Courier. 
>> 
 On Jan 28, 2022, at 1:11 PM, Pierre Alexandre Tremblay 
  wrote:
>>> 
 The result is that if you make a patch on one system with the standard 
 font and open it on another with the same or ver similar (macOS)-sized 
 font, the rendering should be very close.
>>> 
>>> It was close enough indeed, except on Ubuntu 18 which makes a complete 
>>> mess. It might be on my side too.
>> 
>> 
>> Dan Wilcox
>> @danomatika
>> danomatika.com
>> robotcowboy.com
>> 
>> 
>> 
> 



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

Re: [PD] A quick question - a bug or me?

[Christof Ressi]

v0.48
According to the release notes 
(http://msp.ucsd.edu/Pd_documentation/x5.htm#s1), the font handling 
changes have been introduced in 0.48-1.


Christof

On 28.01.2022 15:04, Pierre Alexandre Tremblay wrote:

Oh this is good - now I presume many other patches one someone’s machine will 
look awful if their Linux doesn’t find the font, so I shouldn’t feel too bad. 
I’ll make sure they look decent with what I can expect from v0.48

Thanks!


On 28 Jan 2022, at 13:32, Dan Wilcox  wrote:

Check the actual font used by setting Log level 4 All and compare "detected font" with 
"using font." On Linux, Pd doesn't include the font itself, so it relies on DVSM being 
installed to the system and Tk finding it when the GUI opens. If it can't find DVSM, it reverts to 
a series of backup fonts starting with the old default of Courier.


On Jan 28, 2022, at 1:11 PM, Pierre Alexandre Tremblay  
wrote:


The result is that if you make a patch on one system with the standard font and 
open it on another with the same or ver similar (macOS)-sized font, the 
rendering should be very close.

It was close enough indeed, except on Ubuntu 18 which makes a complete mess. It 
might be on my side too.


Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com





___
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] A quick question - a bug or me?

[Pierre Alexandre Tremblay]

Oh this is good - now I presume many other patches one someone’s machine will 
look awful if their Linux doesn’t find the font, so I shouldn’t feel too bad. 
I’ll make sure they look decent with what I can expect from v0.48

Thanks!

> On 28 Jan 2022, at 13:32, Dan Wilcox  wrote:
> 
> Check the actual font used by setting Log level 4 All and compare "detected 
> font" with "using font." On Linux, Pd doesn't include the font itself, so it 
> relies on DVSM being installed to the system and Tk finding it when the GUI 
> opens. If it can't find DVSM, it reverts to a series of backup fonts starting 
> with the old default of Courier. 
> 
>> On Jan 28, 2022, at 1:11 PM, Pierre Alexandre Tremblay  
>> wrote:
>> 
>>> The result is that if you make a patch on one system with the standard font 
>>> and open it on another with the same or ver similar (macOS)-sized font, the 
>>> rendering should be very close.
>> 
>> It was close enough indeed, except on Ubuntu 18 which makes a complete mess. 
>> It might be on my side too.
> 
> 
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
> 
> 
> 



smime.p7s
Description: S/MIME cryptographic signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] A quick question - a bug or me?

[Dan Wilcox]

Check the actual font used by setting Log level 4 All and compare "detected 
font" with "using font." On Linux, Pd doesn't include the font itself, so it 
relies on DVSM being installed to the system and Tk finding it when the GUI 
opens. If it can't find DVSM, it reverts to a series of backup fonts starting 
with the old default of Courier. 

> On Jan 28, 2022, at 1:11 PM, Pierre Alexandre Tremblay  
> wrote:
> 
>> The result is that if you make a patch on one system with the standard font 
>> and open it on another with the same or ver similar (macOS)-sized font, the 
>> rendering should be very close.
> 
> It was close enough indeed, except on Ubuntu 18 which makes a complete mess. 
> It might be on my side too.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



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

Re: [PD] A quick question - a bug or me?

[Pierre Alexandre Tremblay]

Thanks Dan for this comprehensive reply.

> Pd tries to use the same standard font across all platforms as of around 0.48 
> or 0.49. In 0.52, we now included the italic and bold versions of DejaVu Sans 
> Mono as well.

Highly appreciated.

> The result is that if you make a patch on one system with the standard font 
> and open it on another with the same or ver similar (macOS)-sized font, the 
> rendering should be very close.

It was close enough indeed, except on Ubuntu 18 which makes a complete mess. It 
might be on my side too.

> There is also a text patch with all the GUIs you can use to compare on 
> different systems:
> Help->Browser : Pure Data/7.stuff/tools/sizingtest.pd 

This is good to know - I now have Parallels running with Windows10 and Ubuntu20 
in MacOS so I can see in realtime what they look like.

> I would also ask Alex and the cyclone team as they have deployed a standard 
> help-file format and pushed for some of the required changes in this area.

Oh that is a great pointer - I’ll try to reach for him as I’d like to get it 
right (or at least get challenged by their requests :) - I presume they opened 
a project/pr on GitHub? I’ll check them out.

> Oh, one thing I've forgotten about: the default font is bold on Windows and 
> Linux which normal weight on macOS.

I read about it and it looks a bit different but not enough to cause issues 
with Menlo/DejaVu

Thanks again for the extensive response!

smime.p7s
Description: S/MIME cryptographic signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] A quick question - a bug or me?

[Dan Wilcox]

Oh, one thing I've forgotten about: the default font is bold on Windows and 
Linux which normal weight on macOS.

This is historical but I believe is also due to the font rendering on macOS 
using antialiasing which gives the normal font a similar draw size as the bold 
fonts on the other platforms (slightly a guess here). Another possible reason 
is that the bold fonts render "better" on Windows and Linux which normal 
renders "better" on macOS. Some have called for making them all the same but 
it's been a precedent I don't feel worth changing at least without a broad 
consensus of users. "If it ain't broke..."

> On Jan 28, 2022, at 12:47 PM, Dan Wilcox  wrote:
> 
> Pd tries to use the same standard font across all platforms as of around 0.48 
> or 0.49. In 0.52, we now included the italic and bold versions of DejaVu Sans 
> Mono as well. On macOS, we use a DVSM derivative, Menlo, which is included on 
> the system itself. Details are here:
> 
> https://github.com/pure-data/pure-data/tree/master/font 
> 
> 
> The result is that if you make a patch on one system with the standard font 
> and open it on another with the same or ver similar (macOS)-sized font, the 
> rendering should be very close. The relative sizing of objects and GUIs 
> should be very similar, however not *pixel-perfect*. This is down to small 
> differences in how Tk renderings things on the canvas via the underlying 
> system graphics frameworks. We also imported the tried-and-true object sizing 
> tweaks honed in pd-extended around the same time to help ensure more 
> consistent sizing.
> 
> That being said, I would basically suggest approach layouts with a bit of 
> padding here and here and don't overlying focus on exact pixel alignment of 
> things. GOPs are generally fine regarding sizing etc. There is also a text 
> patch with all the GUIs you can use to compare on different systems:
> 
> Help->Browser : Pure Data/7.stuff/tools/sizingtest.pd 
> 
> I would also ask Alex and the cyclone team as they have deployed a standard 
> help-file format and pushed for some of the required changes in this area.
> 
>> On Jan 27, 2022, at 8:06 PM, pd-list-requ...@lists.iem.at 
>>  wrote:
>> 
>> (Ps any pointer on how to unify looks between OSes welcome - I found some 
>> online, mostly moaning about fonts :)
> 
> 
> Dan Wilcox
> @danomatika 
> danomatika.com 
> robotcowboy.com 
> 
> 
> 


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



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

Re: [PD] A quick question - a bug or me?

[Dan Wilcox]

Pd tries to use the same standard font across all platforms as of around 0.48 
or 0.49. In 0.52, we now included the italic and bold versions of DejaVu Sans 
Mono as well. On macOS, we use a DVSM derivative, Menlo, which is included on 
the system itself. Details are here:

https://github.com/pure-data/pure-data/tree/master/font 


The result is that if you make a patch on one system with the standard font and 
open it on another with the same or ver similar (macOS)-sized font, the 
rendering should be very close. The relative sizing of objects and GUIs should 
be very similar, however not *pixel-perfect*. This is down to small differences 
in how Tk renderings things on the canvas via the underlying system graphics 
frameworks. We also imported the tried-and-true object sizing tweaks honed in 
pd-extended around the same time to help ensure more consistent sizing.

That being said, I would basically suggest approach layouts with a bit of 
padding here and here and don't overlying focus on exact pixel alignment of 
things. GOPs are generally fine regarding sizing etc. There is also a text 
patch with all the GUIs you can use to compare on different systems:

Help->Browser : Pure Data/7.stuff/tools/sizingtest.pd 

I would also ask Alex and the cyclone team as they have deployed a standard 
help-file format and pushed for some of the required changes in this area.

> On Jan 27, 2022, at 8:06 PM, pd-list-requ...@lists.iem.at wrote:
> 
> (Ps any pointer on how to unify looks between OSes welcome - I found some 
> online, mostly moaning about fonts :)


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



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

Re: [PD] pd 0.52-0 test 4 released

[Dan Wilcox]

# macOS universal build status clarification

Ok, my intention was not to spread confusion, so let me rephrase I wrote 
previously:

I have been compiling universal (x86_64 + arm64) builds of both Pd and Tk 
8.6.12 for some months in the fall of 2021. It was working ok, more or less, 
after some adjustments to the build scripts. In late November / early December 
as finalization of the 0.52 release was upon us, I noticed that suddenly builds 
of Tk on my system ended with a non-working Wish.app and subsequent Pd.app. I 
believe this is when I was making test builds linking the newer JACK macOS 
distribution. I provided an arm64-only build instead as a work-around, then 
came holiday time and weeks of our whole family being sick so I haven't done 
any further development in detail since.

I believe this was also noticed on the IEM CI build setup, but perhaps I am 
remembering it incorrectly.

In no way do I imply that we cannot have a universal build, only that it wasn't 
working for me at a moment when we wanted to make a release.

The fix is more less when IOhannes (or whoever) can implement A1 (update the 
build system to a newer version of Xcode/CLITools).

# included pre-built Wish.app needs to be updated

I agree with A2 (don't build Tk every time), however then the included 
pre-build Wish.app also needs to be updated so everyone gets a *canonical* 
version from make app. As it is now, the current pre-built wish is 8.6.10 which 
has numerous small issues on macOS 12 systems, one of which I pointed out on a 
GitHub issue: black header bars on a table view.

For every release which requires rebuilding or updating the Wish.app used to 
make the App .app bundle on macOS, this wish needs to be included in the repo 
and replace the previous version. If we need two separate tarballs ala one for 
"old systems" from Miller's build setup and one for "newer systems" for the IEM 
CI setup, so be it. We can then modify the build system to detect the macOS 
version on the build system and use the appropriate Wish tarball.

In either case, the point is that users do not need to build Tk to get a 
working Pd .app *and* everyone is using the same nominal Tk frameworks. I 
believe I've stressed this before but perhaps it should be added to the release 
notes as an important step since I'm not involved in making the actually 
release zips or dmgs.

> On Jan 25, 2022, at 12:00 PM, pd-list-requ...@lists.iem.at wrote:
> 
> Message: 1
> Date: Mon, 24 Jan 2022 17:56:40 +0100
> From: IOhannes m zmoelnig mailto:zmoel...@iem.at>>
> To: pd-list@lists.iem.at 
> Subject: Re: [PD] pd 0.52-0 test 4 released
> Message-ID: <36ca2d0c-f6bc-764a-32f0-cdae73d16...@iem.at 
> >
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
> 
> On 1/24/22 17:18, Dan Wilcox wrote:
>> There was an issue with building Tk Wish 8.6.12 as a universal build which 
>> stopped this for now.
> 
> no.
> this is not really true, and more importantly i think it spreads confusion.
> 
> the truth (according to john) is:
> - for newer macOS versions, miller uses binaries produced by the iem-ci
> - the iem-ci currently does not build arm64 binaries
>   - simply because the XCode version installed there is too old
> - this means that Pd-core (on the downloads) is only x86_64
> - the iem-ci does not build Tcl/Tk *at all*
>   - instead it uses a pre-built binary (similar to the one found in 
> mac/stuff.tgz)
>   - this pre-built blob is Tcl/Tk-8.6.12 and it is a universal build 
> for arm64 and x86_64
> 
> 
> this raises the following questions:
> Q1: why is the iem-ci not updated to a newer XCode that allows to build 
> arm64 binaries for macOS?
> A1: because I haven't found the time yet to do so
> 
> Q2: why isn't Tcl/Tk build along with Pd
> A2: because I don't want our CI to spend time compiling a helper library 
> that we is not actively developed by *us*
> 
> 
> because of the situation with the externals, i do not consider the 
> current situation extremely bad.
> 
> 
> gfdmst
> IOhannes


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



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

Re: [PD] A quick question - a bug or me?

[Pierre Alexandre Tremblay]

> i compiled pd from source and yes, i'm using jack.

Same here - it works-ish and is simpler to do than SC for sure - so thanks to 
whomever wrote the compile instructions.

>> I’m new to Linux and it is quite chronophage :)
> i'm always hoping it trades some knowledge for the time spent. :)

Indeed it helps understand the beast a bit.

smime.p7s
Description: S/MIME cryptographic signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] A quick question - a bug or me?

[ub]

On 27.01.22 22:31, Pierre Alexandre Tremblay wrote:

This is good news!

I’m curious, did you compile Pd or was there a binary somewhere? If so, do you 
use jack or another audio driver?


i compiled pd from source and yes, i'm using jack.


I’m new to Linux and it is quite chronophage :)


i'm always hoping it trades some knowledge for the time spent. :)




p


On 27 Jan 2022, at 21:27, ub  wrote:

hello,



all works for me.

pd 0.52.1, ubuntu 20.04, flucoma-pd from dev branch at #eeab7248



it's a very cool help patch, by the way. very interactive. nice!



cheers,

ub

On 27.01.22 21:59, Pierre Alexandre Tremblay wrote:

Sorry - they are all here:


https://github.com/flucoma/flucoma-sc/releases/tag/nightly


The whole project is documented here:


https://www.flucoma.org/


And we try to help people understanding it all here:


https://learn.flucoma.org/installation/pd






On 27 Jan 2022, at 20:30, Roman Haefeli 
  wrote:

On Thu, 2022-01-27 at 20:17 +, Pierre Alexandre Tremblay wrote:


 the external works fine out of the help. Even more strange,
sometimes that works for a few minutes before getting these problems.


Where can one get the external?
Roman



___

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