Re: [PD] [sfinfo~]

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

Re: [PD] [sfinfo~]

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.

Re: [PD] [sfinfo~]

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

Re: [PD] [sfinfo~]

@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

Re: [PD] [sfinfo~]

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

Re: [PD] [sfinfo~]

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

Re: [PD] [sfinfo~]

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

Re: [PD] [sfinfo~]

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

Re: [PD] [sfinfo~]

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

Re: [PD] [sfinfo~]

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

Re: [PD] [sfinfo~]

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

Re: [PD] [sfinfo~]

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

Re: [PD] [sfinfo~]

> 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

Re: [PD] [sfinfo~]

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

Re: [PD] [sfinfo~]

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

Re: [PD] [sfinfo~]

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]  

Re: [PD] [sfinfo~]

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

Re: [PD] [sfinfo~]

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

[PD] [sfinfo~]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

# 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

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

> 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. :)

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

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