Re: [PD] pd64 and externals, deken etc?

2024-05-27 Thread Benjamin Wesch
> /usr/lib/pd/extra/zexy/zexy.pd_linux
> ...is the only file found.

there are actually quite a few binaries for a variety of architectures
and pd32 and pd64 in this case - with different file extensions:
zexy.l_i386
zexy.pd_linux
zexy.l_arm
zexy.l_arm64
zexy.linux-i386-64.so
zexy.linux-amd64-64.so
zexy.linux-arm64-64.so
zexy.linux-armv7-64.so

you can find these documented in
https://msp.ucsd.edu/Pd_documentation/x4.htm#s4.1.2.1

cheers,
ben

Am Mo., 27. Mai 2024 um 08:45 Uhr schrieb Peter P. :
>
> * Peter P.  [2024-05-27 08:41]:
> > * IOhannes m zmölnig  [2024-05-26 11:17]:
> > > Am 26. Mai 2024 11:11:53 MESZ schrieb "IOhannes m zmölnig" 
> > > :
> > > >Am 26. Mai 2024 09:40:02 MESZ schrieb "Peter P." 
> > > >:
> > > >>
> > > >
> > > >> Will I have to install specific externals via Deken or apt then?
> > > >
> > > >Via deken: only externals that are compatible will be shown. So when 
> > > >running Pd64, you will only see externals that can deal with double 
> > > >precision (or are precision agnostic, eg pure abstractions).
> > > >
> > >
> > > Also note that some maintainers might have chosen to upload separate pd32 
> > > and pd64 packages for their externals (as opposed to having a single 
> > > package for both variants).
> > > If both pd variants install into the same directory (which is the 
> > > default), then installing the pd64 external will (by default) first 
> > > remove the pd32 external.
> > > You can change this (in the deken preferences).
> >
> > Thanks, do both versions of the compiled externals have the identical
> > filename extension then?
> (Sorry, replying to myself here)
>
> this seems the case, at least for apt-packaged zexy:
> $ dpkg -L pd-zexy | grep .pd_linux
> /usr/lib/pd/extra/zexy/zexy.pd_linux
>
> ...is the only file found.
>
> best, P
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



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


Re: [PD] [PD-announce] Pd 0.55-0 test version released

2024-05-27 Thread Benjamin Wesch
replying to myself here after realizing that i made this quite
complicated, sorry. i get similar results when just doing this on
macos here:

time /Applications/Pd-0.54-1.app/Contents/Resources/bin/pd -send "pd quit"
vs.
time /Applications/Pd-0.55-0test2c.app/Contents/Resources/bin/pd -send "pd quit"

cheers,
ben

Am Do., 16. Mai 2024 um 13:21 Uhr schrieb Benjamin Wesch
:
>
> thanks for looking into this!
> when comparing click-on-app-icon vs. starting
> "/Applications/Pd-0.55-0test2c.app/Contents/Resources/bin/pd" from the
> terminal, i also get slightly different results. the latter seems to
> be a 1 or 2s faster (this was also the way i measured). the former
> even causes the loading icon to appear, which i never saw in the pd
> context iirc.
>
> but then again, i'm not sure if this is actually an issue at all! if
> you don't see it on your side on the same architecture, it may well be
> caused by some weird configuration on my side.
>
> just to document what i did to check the difference - which i hope is
> a valid approach ...  i have this little script "timer_pd.sh":
> #!/bin/bash
> LOG_FILE=$1
> START_TIME=$(gdate +%s.%N)
> while : ; do
>   if grep -q "connected" "$LOG_FILE"; then
> END_TIME=$(gdate +%s.%N)
> DURATION=$(echo "$END_TIME - $START_TIME" | bc -l)
> printf "%s: %.2fs\n" "$LOG_FILE" "$DURATION"
> break
>   fi
>   sleep 0.1
> done
>
> ... and then starting these commands to reset the log and start timer
> and pd in parallel:
> truncate -s 0 pd-0.55-0.log
> ./timer_pd.sh pd-0.55-0.log &
> /Applications/Pd-0.55-0test2c.app/Contents/Resources/bin/pd 2> pd-0.55-0.log &
>
> or obviously the same way:
> truncate -s 0 pd-0.54-1.log
> ./timer_pd.sh pd-0.54-1.log &
> /Applications/Pd-0.54-1.app/Contents/Resources/bin/pd 2> pd-0.54-1.log &
>
> cheers,
> ben
>
> Am Do., 16. Mai 2024 um 12:20 Uhr schrieb Miller Puckette
> :
> >
> > I'm having trouble recreating this - I thik it was happening for a while
> > but now I can't seem to get consistent differences (after launching both
> > versions many times).  Are you launching it by clicking on the Pd icon,
> > or some other way?  (That seems to make a difference).
> >
> > thanks
> >
> > M
> >
> > On 5/15/24 1:25 PM, Benjamin Wesch wrote:
> > > hm, that's really weird. i tried to objectively measure here now with
> > > a script that waits for the "connected" output when starting both
> > > versions in parallel and i consistently get results quite similar to
> > > this:
> > >
> > > pd-0.54-1.log: 0.99s
> > > pd-0.55-0.log: 2.72s
> > >
> > > so my subjective impression was certainly wrong with 5s - but there's
> > > still a noticeable difference.
> > >
> > > cheers,
> > > ben
> > >
> > > Am Mi., 15. Mai 2024 um 11:51 Uhr schrieb Miller Puckette
> > > :
> > >> Hmm... I'm not getting that on mine.  The startup order is indeed
> > >> different -
> > >>
> > >> the GUI doesn't start up until after any startup stuff has been done
> > >> (loading libraries,
> > >>
> > >> etc).  But I don't _think_ the overall time spent is different - do let
> > >> me know if you're
> > >>
> > >> finding otherwise :)
> > >>
> > >> Miller
> > >>
> > >> On 5/15/24 10:56 AM, Benjamin Wesch wrote:
> > >>> thanks a lot for the test release!
> > >>> what i noticed here (apple m2) in addition to the missing console
> > >>> output: pd now takes ~5s to start. not a big deal obviously, but it's
> > >>> a huge difference compared to 0.54, where the gui is ready after ~1s.
> > >>>
> > >>> cheers,
> > >>> ben
> > >>>
> > >>> Am Di., 14. Mai 2024 um 16:26 Uhr schrieb Miller Puckette
> > >>> :
> >  To Pd-announce:
> > 
> >  Pd version 0.55-0 test2 is available from 
> >  http://msp.ucsd.edu/software.htm
> >  or (source only) via github: 
> >  https://urldefense.com/v3/__https://github.com/pure-data/pure-data__;!!Mih3wA!EYIIRk4dAHKvFUeDU8oAbbLqs85QxrQMAIKPfOBo4CV429prsy7Mkhr6G-eFg56gAQv31-q3Q0hYoDbWzZpR$
> > 
> >  There was no "test1" - it never made it through the release process.  
> >  Also,
> >  for Mac users, the app will show up as "Pd-0.55-0test2c" but in fact
> >  it's just test2.
> > 
> >  cheers
> >  Miller
> > 
> > 
> > 
> > 
> > 
> >  ___
> >  Pd-announce mailing list
> >  pd-annou...@lists.iem.at
> >  https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-announce__;!!Mih3wA!EYIIRk4dAHKvFUeDU8oAbbLqs85QxrQMAIKPfOBo4CV429prsy7Mkhr6G-eFg56gAQv31-q3Q0hYoBRj2MA2$
> >  ___
> >  Pd-list@lists.iem.at mailing list
> >  UNSUBSCRIBE and account-management -> 
> >  https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!EYIIRk4dAHKvFUeDU8oAbbLqs85QxrQMAIKPfOBo4CV429prsy7Mkhr6G-eFg56gAQv31-q3Q0hYoBYYetOc$
> > >>>
> > >>> ___
> > >>> Pd-list@lists.iem.at mailing list
> > >>> UNSUBSCRIBE and account-manage

Re: [PD] pd64 and externals, deken etc?

2024-05-27 Thread IOhannes m zmoelnig

On 5/27/24 08:44, Peter P. wrote:


Thanks, do both versions of the compiled externals have the identical
filename extension then?


no.


(Sorry, replying to myself here)

this seems the case, at least for apt-packaged zexy:
$ dpkg -L pd-zexy | grep .pd_linux
/usr/lib/pd/extra/zexy/zexy.pd_linux

...is the only file found.


```
$ dpkg -L pd-zexy | grep "zexy\."
/usr/lib/pd/extra/zexy/zexy.linux-amd64-64.so
/usr/lib/pd/extra/zexy/zexy.pd_linux
```

mgfasdr
IOhannes




OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] [PD-announce] Pd 0.55-0 test version released

2024-05-27 Thread IOhannes m zmoelnig

On 5/27/24 09:24, Benjamin Wesch wrote:

replying to myself here after realizing that i made this quite
complicated, sorry.


it depends what you actually want to measure.



i get similar results when just doing this on
macos here:

time /Applications/Pd-0.54-1.app/Contents/Resources/bin/pd -send "pd quit"
vs.
time /Applications/Pd-0.55-0test2c.app/Contents/Resources/bin/pd -send "pd quit"

which measures the time for the core to start and quit.
this is not the same as the time it takes for Pd to startup with a 
functional GUI.
esp. with Pd-0.55 (where the GUI is started late), the numbers you get 
might significantly differ from what you are experiencing when you start 
Pd interactively.


here's what i get on my Debian system using `hyperfine` (which runs the 
application multiple times, to cater for disk-caching and whatnot)


| version | flags  | time|
|-||-|
| 0.54-1  || 131.7 ms ±  21.8 ms |
| 0.54-1  | -nogui | 4.7 ms ±   2.6 ms   |
| 618b63  || 38.4 ms ±   3.6 ms  |
| 618b63  | -nogui | 4.1 ms ±   2.3 ms   |

the 0.54-1 version is the one packaged in Debian.
the "618b63" version is current master (slightly after 0.55-0test3), but 
i haven't found any significant differences between `master`, 
`0.55-0test3` and `0.55-0test2c`)


tests are run on a Debian/amd64 system (i7-13700K).

if you want to measure the time until the GUI is fully available, you 
probably have to use a GUI plugin that quits Pd from the GUI side.



mfdgrasd
IOhannes


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] pd64 and externals, deken etc?

2024-05-27 Thread Peter P.
* IOhannes m zmoelnig  [2024-05-27 11:51]:
> On 5/27/24 08:44, Peter P. wrote:
> > > 
> > > Thanks, do both versions of the compiled externals have the identical
> > > filename extension then?
> 
> no.
> 
> > (Sorry, replying to myself here)
> > 
> > this seems the case, at least for apt-packaged zexy:
> > $ dpkg -L pd-zexy | grep .pd_linux
> > /usr/lib/pd/extra/zexy/zexy.pd_linux
> > 
> > ...is the only file found.
> 
> ```
> $ dpkg -L pd-zexy | grep "zexy\."
> /usr/lib/pd/extra/zexy/zexy.linux-amd64-64.so
> /usr/lib/pd/extra/zexy/zexy.pd_linux

Thanks for the correcty grep syntax.

Aja,pd-zexy 2.4.1-4 
on my Debian stable system provides only 
/usr/lib/pd/extra/zexy/zexy.pd_linux
but pd-zexy 2.4.3-1 on testing does contain both precisions then,
brilliant!

So the bottom line might then be:
Deken developers should ideally package both single and double precision
binaries of their externals into the same package.

Deken users should note that newer version packages uninstall older
version packages, as this might remove a single precision package when
installing a double precision package with a higher version number
(unless that feature is disabled in dekens preferences).

right?

best, P



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


Re: [PD] [PD-announce] Pd 0.55-0 test version released

2024-05-27 Thread IOhannes m zmoelnig

On 5/27/24 12:15, IOhannes m zmoelnig wrote:



here's what i get on my Debian system using `hyperfine` (which runs the 
application multiple times, to cater for disk-caching and whatnot)


| version | flags  | time    |
|-||-|
| 0.54-1  |    | 131.7 ms ±  21.8 ms |
| 0.54-1  | -nogui | 4.7 ms ±   2.6 ms   |
| 618b63  |    | 38.4 ms ±   3.6 ms  |
| 618b63  | -nogui | 4.1 ms ±   2.3 ms   |



[...]


if you want to measure the time until the GUI is fully available, you 
probably have to use a GUI plugin that quits Pd from the GUI side.


so i went ahead and created the following GUI-plugin named 
"quitter-plugin.tcl":

```tcl
after idle {pdsend "pd quit"}
```

now Pd will quit once the GUI has become "idle" (right after startup). 
which gives me the following stats:


| version | time|
|-|-|
| 0.54-1  | 249.9 ms ±  61.8 ms |
| 618b63  | 202.3 ms ± 119.3 ms |

so you can see, it is much slower than the naive "-send 'pd quit'" test.

Pd-0.55 is still much faster that 0.54-1, at least for me.


gdmfar
IOhannes


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


[PD] stable pd64 release? "was: pd64 and externals, deken etc?"

2024-05-27 Thread Alexandre Torres Porres
While we're discussing pd64, can we make it 'official' and have it as 'non
beta' for the next 0.55 release?

If Miller can't take care of yet this other compilation, he can put a link
for p64 binaries in his website that redirects to 'puredata.info' p64
downloads.

I will only bother to compile ELSE and Cyclone when this is finally
officially "ok" and easily available :)

If we agree to have this worked out I can also make the current
state clearer on the documentation (manual and stuff).

cheers


Em seg., 27 de mai. de 2024 às 08:28, Peter P. 
escreveu:

> * IOhannes m zmoelnig  [2024-05-27 11:51]:
> > On 5/27/24 08:44, Peter P. wrote:
> > > >
> > > > Thanks, do both versions of the compiled externals have the identical
> > > > filename extension then?
> >
> > no.
> >
> > > (Sorry, replying to myself here)
> > >
> > > this seems the case, at least for apt-packaged zexy:
> > > $ dpkg -L pd-zexy | grep .pd_linux
> > > /usr/lib/pd/extra/zexy/zexy.pd_linux
> > >
> > > ...is the only file found.
> >
> > ```
> > $ dpkg -L pd-zexy | grep "zexy\."
> > /usr/lib/pd/extra/zexy/zexy.linux-amd64-64.so
> > /usr/lib/pd/extra/zexy/zexy.pd_linux
>
> Thanks for the correcty grep syntax.
>
> Aja,pd-zexy 2.4.1-4
> on my Debian stable system provides only
> /usr/lib/pd/extra/zexy/zexy.pd_linux
> but pd-zexy 2.4.3-1 on testing does contain both precisions then,
> brilliant!
>
> So the bottom line might then be:
> Deken developers should ideally package both single and double precision
> binaries of their externals into the same package.
>
> Deken users should note that newer version packages uninstall older
> version packages, as this might remove a single precision package when
> installing a double precision package with a higher version number
> (unless that feature is disabled in dekens preferences).
>
> right?
>
> best, P
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] [PD-announce] Pd 0.55-0 test version released

2024-05-27 Thread Benjamin Wesch
thanks a lot for pointing out 'hyperfine' and for providing this
somewhat self-defeating plugin.

comparing 0.54-1 to the artifact from the iem pipeline for 618b6325
now, i get the results below. side notes:
* the plugin is present in all cases, but should only affect the last
comparison, i assume
* it's a bit irritating to me that quitting 618b63 is slower via
'-send' flag than through the plugin, but this was obviously caused by
outliers (although i got similar results with another 10 runs)

| version | flags  | time  |
|-||---|
| 0.54-1  | -nogui -send "pd quit" |   78.5 ms ±0.6 ms |
| 618b63  | -nogui -send "pd quit" |   77.9 ms ±1.3 ms |
| ||   |
| 0.54-1  |-send "pd quit" |  327.2 ms ±5.6 ms |
| 618b63  |-send "pd quit" | 2512.9 ms ± 1523.3 ms |
| ||   |
| 0.54-1  ||  396.5 ms ±4.7 ms |
| 618b63  || 2117.4 ms ±  518.0 ms |

... and a bit of system info:

Model Name: MacBook Air
Model Identifier: Mac14,2
Model Number: MLY33D/A
Chip: Apple M2
Total Number of Cores: 8 (4 performance and 4 efficiency)
Memory: 8 GB

System Version: macOS 14.5 (23F79)
Kernel Version: Darwin 23.5.0

cheers,
ben

Am Mo., 27. Mai 2024 um 15:08 Uhr schrieb IOhannes m zmoelnig :
>
> On 5/27/24 12:15, IOhannes m zmoelnig wrote:
> >
> >
> > here's what i get on my Debian system using `hyperfine` (which runs the
> > application multiple times, to cater for disk-caching and whatnot)
> >
> > | version | flags  | time|
> > |-||-|
> > | 0.54-1  || 131.7 ms ±  21.8 ms |
> > | 0.54-1  | -nogui | 4.7 ms ±   2.6 ms   |
> > | 618b63  || 38.4 ms ±   3.6 ms  |
> > | 618b63  | -nogui | 4.1 ms ±   2.3 ms   |
> >
> >
> [...]
> >
> > if you want to measure the time until the GUI is fully available, you
> > probably have to use a GUI plugin that quits Pd from the GUI side.
>
> so i went ahead and created the following GUI-plugin named
> "quitter-plugin.tcl":
> ```tcl
> after idle {pdsend "pd quit"}
> ```
>
> now Pd will quit once the GUI has become "idle" (right after startup).
> which gives me the following stats:
>
> | version | time|
> |-|-|
> | 0.54-1  | 249.9 ms ±  61.8 ms |
> | 618b63  | 202.3 ms ± 119.3 ms |
>
> so you can see, it is much slower than the naive "-send 'pd quit'" test.
>
> Pd-0.55 is still much faster that 0.54-1, at least for me.
>
>
> gdmfar
> IOhannes
> ___
> 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] pd64 and externals, deken etc?

2024-05-27 Thread Roman Haefeli
On Mon, 2024-05-27 at 11:50 +0200, IOhannes m zmoelnig wrote:

> ```
> $ dpkg -L pd-zexy | grep "zexy\."
> /usr/lib/pd/extra/zexy/zexy.linux-amd64-64.so
> /usr/lib/pd/extra/zexy/zexy.pd_linux
> ```

On a somewhat related note, I tried my first floatsize=64 build and
pd64 refused to load it. I only noticed after that I was using pd-lib-
builder v0.6.0 and support for the floatsize=64 flag was only added in
the v0.7.0.

Until I actually tried to load the binary with pd64, I had no
indication that I was still building for pd (32bit). I wonder if there
is an (easily scriptable) way of detecting the floatsize of the
resulting binary. Messing things can happen quickly and I would like to
avoid that as far as possible, of course.

Roman



signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] pd64 and externals, deken etc?

2024-05-27 Thread IOhannes m zmölnig
Am 27. Mai 2024 23:13:56 MESZ schrieb Roman Haefeli :
>
>Until I actually tried to load the binary with pd64, I had no
>indication that I was still building for pd (32bit). I wonder if there
>is an (easily scriptable) way of detecting the floatsize of the
>resulting binary.
Package your external with the `deken` cmdline tool?
(A poor man's substitute would be to just grep for `class_new64`)

mfg.sfg.jfd
IOhannes


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


Re: [PD] pd64 and externals, deken etc?

2024-05-27 Thread Roman Haefeli
On Tue, 2024-05-28 at 06:07 +0200, IOhannes m zmölnig wrote:
> Am 27. Mai 2024 23:13:56 MESZ schrieb Roman Haefeli
> :
> > 
> > Until I actually tried to load the binary with pd64, I had no
> > indication that I was still building for pd (32bit). I wonder if
> > there
> > is an (easily scriptable) way of detecting the floatsize of the
> > resulting binary.
> Package your external with the `deken` cmdline tool?

Works! (with an up-to-date Deken)

> (A poor man's substitute would be to just grep for `class_new64`)

Nice. That's what I was after. Thanks!

Roman




signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list