Hi Roman,

I tried the netpd-gui-dropdown . . . I installed netpd and the latest Pd vanilla.

The first time I tried it didn't create at all. Redownloaded today and it did create - except for [netpd-mutex MXDROPDOWN].

This has probably to do with the fact that I just created the help patch on the Desktop of my Windows machine where no externals are registered.

Looks pretty good and configurable. However, I did not see how to get a value from clicking on a menu item. Maybe it has to do with the missin [netpd-mutex MXDROPDOWN].

I could also not get any colors to change so far - only grey and black atm. I'll have to keep checking it out a bit further.

It would definitely need a re-implementation of my current dropdown menus and would take some time once I have it running the way I need it.

BTW, netpd looks really interesting! I'll have to take another (closer) look at it as soon as I have a bit more time.

Thanks, Roman, for pointing me at this! Ingo

-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Roman Haefeli Sent: Friday, April 14, 2023 4:05 PM To: pd-list@lists.iem.at Subject: Re: [PD] Pd complete listing of internal Pd messages? - sending to the Pd window

On Fri, 2023-04-14 at 15:47 +0200, Ingo wrote:

[pmenu] seems to use the size of the console font. So by changing this with an internal Pd message I could change my [pmenu] font size on the fly.

Did you try the vanilla drop-down abstraction with configurable font size I posted some days ago?

https://github.com/reduzent/netpd/blob/main/includes/netpd-gui-dropdown.pd https://github.com/reduzent/netpd/blob/main/includes/netpd-gui-dropdown-help...

Roman

Hi Roman,

after getting the [netpd-mutex] abstaction in place everything is working fine. Cool!

I'll have to make a few changes for my usage though.

• I need to have numbers and not symbols coming from the menu output. (menus like MIDI program banks will change when banks change or when

presets are reprogrammed, changed or moved. It's complicated enough to get the menus updated reliably after bank changes or changes of the MIDI channel.)

• the dropdown menus need to be local since I have quite a few of them in a

single patch. So an outlet instead of a $0-send will most likely be required. Unless I come up with a simple strategy to let the menu-triggering part know the $0 value of each connected dropdown menu. Seems more complicated than adding an outlet - especially since my code is written for [pmenu] which does have an inlet and outlet.

• I need multiple definable columns since displaying 128 MIDI programs needs

4-5 columns to fit on the screen. I didn't see anything so far . . . (I might have missed a number of things so far, though.)

• I'll probably have to synchronize the hight and width with the font size to

have only a single number change instead of three. Since there is no font change option it looks like it should be predictable. The names are limited to 14 characters.

I'm not sure if placing large dropdown menus always on the screen to be fully visible has been taken care of. On [pmenu] this seems to work on AMD machines it but does not work on Intel or Arm units. On large menues the part on the right or bottom is often outside of the screen. The AMD machines always move the menu inside of the screen. Unfortunately I'm using mostly Intel and Arm.

Since the [netpd-gui-dropdown] is an abstraction it shouldn't be a big issue unless I'll run into problems with the "data structures" part. I have never used data structures so far. I guess this will be the time to start getting going with it . . . I'm suspecting that implementing multiple settable columns could require messing with data structures.

It would have been nice to simply find out the name of the Pd console for sending internal Pd messages until I get done with all of it. Until then the software is probably not going to be usable with small screens for a while. Oh well . . . (My users don't have access to the regular Pd gui - it's a hardware box with a dedicated user interface for non-programmers.)

Ingo

-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Roman Haefeli Sent: Friday, April 14, 2023 8:43 PM To: pd-list@lists.iem.at Subject: Re: [PD] Pd complete listing of internal Pd messages? - sending to the Pd window

On Fri, 2023-04-14 at 17:39 +0200, Ingo wrote:

I tried the netpd-gui-dropdown . . . I installed netpd and the latest Pd vanilla.

Actually, you don't need a full netpd installation for [netpd-gui- dropdown] to work. I thought it is a standalone abstraction and forgot about:

except for [netpd-mutex MXDROPDOWN].

that is just another abstraction to make sure that at most one instance of [netpd-gui-dropdown] is active. [netpd-gui-dropdown] still works without it, but user experience can get messy if many overlapping dropdown are active.

This has probably to do with the fact that I just created the help patch on the Desktop of my Windows machine where no externals are registered.

Of course - like with any other abstraction - you need to put it somewhere where your patch finds it. Or tell your patch where to find it with [declare -path <path-to-folder-containing-abstraction>]

Looks pretty good and configurable. However, I did not see how to get a value from clicking on a menu item.

There is no outlet, the communication works through a send/receive symbol specified by first argument.

[netpd-gui-dropdown $0.mydropdown]

[r $0.mydropdown] | [route selected] | [print] <- print what you selected with [netpd-gui-dropdown]

Maybe it has to do with the missin [netpd-mutex MXDROPDOWN].

No.

I could also not get any colors to change so far - only grey and black atm.

Send a message like 'select_box_color 800' to it. Please note that color values use data structures color encoding: 800 = red 80 = green 8 = blue

I'll have to keep checking it out a bit further.

Also note, that when you increase the font size, you might need to increase the height as well, like

[fontsize 16, height 20( | [s $0.mydropdown]

Roman

I have nothing much to say, but it appears that there has been some idea

recently that the "CPU" is a prime culprit if things don't work.

I don't think so (esp if it boils down to a difference between AMD and

Intel, which are virtually the same for all things Pd does).

A much more interesting difference would be the version of Pd and OS.

If you do think the CPU is to blame, it would also help to specify the

exact CPU model (there's a difference between a good old i386 CPU from Intel

and a Pentium III, but less so between modern Intel and AMD CPUs)

That's not to say that the CPU information isn't important when hunting

down bugs.

mfg.sfg.jfd IOhannes

I have 5 different AMD computer hardware versions from the lat 12 years until now. I'm running Debian 9.5 with Pd 0.49 on all of them. As a matter of fact I use dd copies of the same drive. I'm only loading a few hardware specific files differently - like e.g. /etc/modprobe.d/alsa-base.conf and /var/lib/alsa/asound state to get sound.

All testing has been done with the same system drive (or copy thereof) and the same Pd software that is compatible in almost all cases.

There is e. g. no way to use xrandr "panning" on any of the AMD boards that works flawlessly on Intel and ARM. xrandr itself works fine for changing the screen size but not for panning. AMD processors ignore commands which include --panning.

I cannot find any information from Google on the internet about the different behavior of these processors in terms of xrandr. One person that I found after quite some time had the same issue wth AMD / Intel on a forum and got no answer.

I was surprised that [pmenu] opens large dropdown menus within the screen on AMD while they are opening directly on the mouse pointer on Intel or ARM. Therefore on the latter two platforma the visibility might be incomplete.

While many things are identical on the Intel machines and AMD machines certain things do behave differently. All of my AMD computers crashed immediately when starting my patch with a Gem created startup image. I tried this on 5 different AMD computer hardwares. There was no problem when doing the same thing on an Intel board with the same system drive. Even the Raspberry Pi 4 (which runs obviously on a different operating system) had no issues with the code.

So these hardware platforms are definitely really close to each other but as far as I can tell they are not identical.

Ingo

-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of IOhannes m zmölnig Sent: Sunday, April 16, 2023 9:29 AM To: pd-list@lists.iem.at Subject: Re: [PD] Pd complete listing of internal Pd messages? - sending to the Pd window

Am 15. April 2023 18:24:32 MESZ schrieb Ingo ingo@miamiwave.com:

On [pmenu] this seems to work on AMD machines it but does not work on

Intel or Arm units.

I have nothing much to say, but it appears that there has been some idea recently that the "CPU" is a prime culprit if things don't work.

I don't think so (esp if it boils down to a difference between AMD and Intel, which are virtually the same for all things Pd does).

A much more interesting difference would be the version of Pd and OS.

If you do think the CPU is to blame, it would also help to specify the exact CPU model (there's a difference between a good old i386 CPU from Intel and a Pentium III, but less so between modern Intel and AMD CPUs)

That's not to say that the CPU information isn't important when hunting down bugs.

mfg.sfg.jfd IOhannes

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