Re: [PD] Error message with 53.1 on M1
On Thu, 2024-04-11 at 10:13 +0200, Jean-Marie Adrien wrote: > > any idea ? > I don't know what part the externals or abstractions [Spat] and [gate1] are coming from. Can you reproduce the error without using any externals? If those are abstractions, can you share them or copy them into your patch? 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] Add to documentation: makenote accepts lists in its leftmost inlet
On Thu, 2024-03-14 at 15:34 +0100, Peter P. wrote: > > the help patch for [makenote] could mention that the object accepts a > list in its leftmost inlet as well, or is this behavior taken for > granted along all message-objects? > Yes, this my understanding. When list messages are received on the left-most inlet, the atoms are spread over the inlets. [9 7( | [- ] | [2 \ 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] RIP Ed Kelly
Sad news. I'm not sure we ever met. Thanks for sharing his music. I'm currently listening. Roman On Mon, 2024-03-11 at 10:08 +, Chris McCormick wrote: > Sad to hear this. So long, Ed. > > I believe this was his most recent work. Love this album. > > https://synchroma.bandcamp.com/album/driftwood > > Maybe we can listen to it again today and remember him. 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] AOO v2.0-pre3 release
On Tue, 2024-01-30 at 01:42 +0100, Christof Ressi wrote: > > after 3 1/2 years (!) I am very happy to announce that a new pre- > release > for AOO 2.0 is now available on Deken! That's great news! Thanks for all the work, time and effort spent for this excellent piece of software. Our group has been using AoO extensively for testing and experimenting, but also for concerts and other telematic performances and it has served us really well so far. We're looking forward to the final 2.0 release! 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] protect [drawnumber] from mouse interaction
On Thu, 2024-01-11 at 12:35 -0300, Alexandre Torres Porres wrote: > so, I created a single issue for these [drawunumber] related > things https://github.com/pure-data/pure-data/issues/2171 > Ok, thanks. I think all of your proposals are desirable. 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
[PD] protect [drawnumber] from mouse interaction
Hi all Is there a conceptual reason that [drawpolygon]/[filledpolygen] support -x, xr, xe and [drawnumber] does not? I sometimes use [drawnumber] as labels and would like to make the numbers non-editable. 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] Way to dynamically route audio in dynamic patching abstractions
On Wed, 2024-01-03 at 12:22 +, Martin Dupras wrote: > I'm trying to make dynamically created abstractions get inserted into > signal chains without using patch cords. In other words, something > like the attached diagramme. > Screenshot 2023-12-14 at 17.22.32.png > > The issue is that [receive~] can be set with a message but [send~] > cannot. You could use the [throw~] and [catch~ ] for dynamic outputs, the same way you can use [send~ ] and [receive~] for dynamic inputs. 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] 2D radio buttons object or abstraction?
On Thu, 2023-12-14 at 13:31 -0300, Alexandre Torres Porres wrote: > > Virtually all of GUI objects in ELSE should ideally be compiled > objects and I didn't do it yet cause tcl/tk is a nightmare and I > havent figured it out quite well... a couple of things I'd like is to > have a nice properties window. Another nice thing could be easily > resizing by click and drag. For mtx.ctl, I wanna have another option > with knobs instead of toggles, to make it a matrix mixer... now that > I have a nice compiled [knob] object in Pd, that can happen. OK, sounds sensible to me now. Thanks. > > I can modify and adapt > > an abstraction and see how it works internally. > > Good, it's there for you to have fun even if it gets replaced :) and > github preserves history Yeah, right :-) 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] 2D radio buttons object or abstraction?
Hi Alex On Thu, 2023-12-14 at 12:14 -0300, Alexandre Torres Porres wrote: > It will happen eventually, as a full compiled object. [mtx.ctl] is a pretty neat abstraction. Why do you want it to rewrite as a (from a user perspective) immutable object? I can modify and adapt an abstraction and see how it works internally. Not so much with a compiled object. 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] 2D radio buttons object or abstraction?
On Tue, 2023-12-12 at 11:30 +, Martin Dupras wrote: > Before reinventing the wheel: does anyone know of a library that > would contain something akin to radio buttons but in 2D? Check out [carlito-grid] from: https://github.com/reduzent/netpd-instruments (in the abs folder). It also has a help patch. 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] How to deal with externals for both 64 and 32-bit Pd
On Wed, 2023-12-06 at 11:16 +0100, IOhannes m zmoelnig wrote: > On 12/6/23 09:12, Roman Haefeli wrote: > > Just compile it against the m_pd.h of the double-precision edition > > of > > Pd. > > this won't work, as the "m_pd.h" for Pd64 and Pd32 are exactly the > same. > > instead set the "PD_FLOATSIZE" macro to 64 when building the > external. > > reasoning: Thanks for the clarifications. Makes all totally sense. I shouldn't have posted without knowing better. 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] How to deal with externals for both 64 and 32-bit Pd (was: Re: [PD-announce] Pd 0.54-1 released)
On Wed, 2023-12-06 at 09:43 +0200, Alexandros Drymonitis wrote: > > The question now is how to have both versions run happily side by > side? > On the 64-bit version I did find zexy (but some other libraries I > searched for, including my own, neuralnet, were not available - not a > surprise for my own, I haven't compiled it for the 64-bit version), > but > installing it through deken, breaks compatibility with the 32-bit > version (I guess it overrides it). You could configure different install and search paths for single- and double-precision versions of Pd. I don't know if they share the config file. If they do, you would have to adjust the config whenever you switch between them. > So when I open the 32-bit version, > zexy is no longer available. If I install it through deken from the > 32-bit Pd, then it's not available for the 64-bit Pd. > > Another question is, how to compile externals for 64-bit Pd? I would > like to offer [neuralnet] for this version too. Just compile it against the m_pd.h of the double-precision edition of Pd. That's not a very qualified statement, though. I haven't tried it myself yet. And from what I read about the topic, not all sources are compatible with Pd64 right away. 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] [PD-announce] Pd 0.54-1 released
On Wed, 2023-12-06 at 09:25 +0200, Alexandros Drymonitis wrote: > This might be obvious, but how is the 64-bit version launched? I > installed Pd from Debian backports, but I can't see any pd64 or > puredata64 executable on my system. > puredata64 is shipped with package puredata64: apt-get install puredata64 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] [PD-announce] ELSE 1.0-0 rc10 and live electronics tutorial released
On Mon, 2023-11-13 at 23:09 -0300, Alexandre Torres Porres wrote: > > > Didn't we take care of that some time before? like the last update or > something? Wasnt it workin in rc9? it's the same binary and > dependencies... Yes. Nevertheless, rc9 ships with a build of sfont~ that has libpcre3 included, while rc10 ships with a build of sfont~ that links to the system version of libpcre3. rc9 and rc10 definitely don't use the same build of sfont~. 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] shell external for raspberry pi aarch64
On Tue, 2023-10-31 at 15:06 +0800, Chris McCormick wrote: > On 31/10/23 2:52 am, Roman Haefeli wrote: > > There is the [command] external, which is a fork of [ggee/shell] > > and > > is meant as its successor. It's available for Raspberry Pi (32 and > > 64 > > bit) through Deken. > > If I type "command" into the Deken search I get `deken-externals` as > the > only result. If I install this package I can't instantiate > `[command]` > after it's installed. Is this the right package? No. The package name is 'command'. This is how it looks like on a Raspberry Pi with Rapsberry Pi OS (Bullseye) arm64: 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] shell external for raspberry pi aarch64
On Mon, 2023-10-30 at 18:21 +0100, Edwin van der Heide wrote: > > Is there an alternative 64 bit version of a shell object available > for the PI or is there another way to go? There is the [command] external, which is a fork of [ggee/shell] and is meant as its successor. It's available for Raspberry Pi (32 and 64 bit) through Deken. 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] tcpsend disconnects
Hey Csaba On Thu, 2023-10-26 at 19:51 +0200, Csaba Láng wrote: > I am struggling with this for many years, and looks like cannot solve > the issue of the tcpsend object which disconnects by itself. Which [tcpsend] are you talking about? There are two flavors around: * mrpeach (unmaintained) * iemnet (recommended) > Would be easy to reconnect if I had an outlet with the info if > connected or not like netsend has. I checked iemnet's [tcpsend] and it has only one outlet whose sole purpose is to indicate whether it is connected or not. > Is there any solution to keep it connected stable? It appears that the outlet only sends 0, if the disconnect was initiated by [tcpsend] itself. It happily stays at 1, if the other end quits the connection. This is clearly a bug and should be reported: https://git.iem.at/pd/iemnet/-/issues Until this gets fixed, you could: * replace [tcpsend] with [tcpclient]. Its third outlet reports the connection state correctly. * use [netsend -b] from Pd which reports connection state correctly on the first outlet Actually, I don't quite see the purpose of [tcpsend] as [tcpclient] covers all its capabilities. Probably it is there only for historic reasons. 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] Is the source server down?
On Fri, 2023-09-22 at 08:38 +0200, IOhannes m zmölnig wrote: > > last night, miller's site finally got https:// support [...] 拾 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] maxlib on OSX version?
On Wed, 2023-09-20 at 13:09 +0200, Christof Ressi wrote: > I hit the same problem when trying to run a project on a friend's M1 > MacBook. I have compiled "maxlib" and "mrpeach" for M1, but haven't > bothered uploading it to Deken. Maybe I manage to do it tonight > (before I forget again). Both, maxlib and mrpeach, are not actively maintained anymore. mrpeach was split into separate repos: * binfile * slip * osc * iemnet (forked from mrpeach/net) which is compatible and definitely more mature From what I can tell, there isn't a simple replacement for maxlib, but from what I remember, it doesn't really provide anything useful nowadays. @Raphael, since you seem to need osc from mrpeach, I advise you to convert your patches to use the osc library directly. Even osc is not strictly necessary nowadays since the introduction [oscformat] and [oscparse] in Pd vanilla. @Christof, while it is a nice effort to provice arm64/macOS builds of mrpreach and maxlib, it also keeps the confusion about their maintenance state alive. I, personally, prefer to rather keep things clear and help people do the migration. At least, I believe that it is more sustainable on the long run. Please consider my thoughts, but in no way would I grant myself the authority to tell people what to do. Roman > Christof > On 20.09.2023 12:52, rafael.racc...@blindekinder.com wrote: > > > > > Ok, I managed to create my own [scale] (attached). > > > > but for mrpeach? I need OSC collection. What is the alternative? > > > > rph-r > > > > Raphael Raccuia a écrit : > > > > > Oh, and same for mrpeach... > > > > > > Le 19/09/2023 à 23:33, rafael.racc...@blindekinder.com a écrit : > > > > > > > Hej!! > > > > I can't find maxlib on 0.54 OSX version. I seached in Deken > > > > and on the web. I need [scale] object. > > > > I build the patch on Linux and now it will run on a mac for > > > > the intallation. > > > > > > > > thank you in advance! > > > > > > > > rph-r > > > > > > > > > > > > ___ > > > > Pd-list@lists.iem.at mailing list > > > > UNSUBSCRIBE and account-management -> > > > > https://lists.puredata.info/listinfo/pd-list > > > ___ > > > Pd-list@lists.iem.at mailing listUNSUBSCRIBE 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 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] Uploading an abstraction to Deken
On Wed, 2023-09-06 at 20:51 +0800, Chris McCormick wrote: > Hello list, > > Is there a webpage which explains how to provision and upload a > simple > abstractions library to Deken in 2023? If your question is how to upload an abstraction library as opposed to an external library: There is no difference. If your question is how to upload Deken packages in general, then read: https://github.com/pure-data/deken/blob/main/developer/README.md but basically just: deken upload --version 0.7 --name mylib path/to/mylib 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] cannot find ggee external - I need [shell] or [command]
Dear Csaba On Fri, 2023-09-01 at 02:14 +0200, Csaba Láng wrote: > > Can someone give me a compiled COMMAND object from ggee for windows? [command] (which is a fork of ggee's shell, but was never part of any distribution) doesn't support Windows. I guess [shell] already didn't support Windows. 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] Problem with this (involved) abstraction for XY
> On 21 Aug 2023, at 06:40, Alexandre Torres Porres > > wrote: > > > > you can get/use/steal my mouse pad external GUI [else/pad] - On Mon, 2023-08-21 at 08:26 +0100, Pierre Alexandre Tremblay wrote: > > Thanks for the kind offer but I would never dare :) This kind of speak makes me slightly uncomfortable as it implies a notion of ownership that is contrary to the license used for that software. Of course, I simply (re-)use software for my own purposes without notification if it is licensed accordingly. I'm not accusing you of being serious here, but the tongue-in-cheek is only understood in relation to a deeply ingrained capitalistic sense of property. Why is this is notion even apparent on a ML about FLOSS software? 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] 0.54-0test2 released
On Sun, 2023-07-02 at 21:09 -0700, Miller Puckette wrote: > I've released 0.54-0 test 2 - I think all the known show-soppers are > taken care of... uness something appears broken I'll plan to make the > 0.54-0release tomorrow. I couldn't find a 0.54-0test2 tag, so I tested current master (49daa9b42894). I couldn't spot any show stoppers. Tabbed preferences are nice. To my surprise, I don't see any GUI redrawing anymore triggered by data structures, which makes the GUI much more responsive (compared to before). One minor thing: Recently, the Pd console font got bigger, which makes it the Pd window look even smaller. 43 chars/line is way too narrow. 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] Number atom box limits overstepped
On Thu, 2023-05-11 at 16:54 +0200, Christof Ressi wrote: > > I think we should generally follow the principle of least surprise. +1 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] Audio latency on linux
On Wed, 2023-05-10 at 19:04 +0200, Orm Finnendahl wrote: > > jack_delay reports a 9.6 ms roundtrip delay through the analog > outputs > with a vector size of 64, so it is not the driver and in principle > should be possible to get a lower latency in linux. When using -callback (as Christof already suggested), you should get exactly the same latency as measured by jack_delay. And in my experience, that is indeed the case. While using the callback scheduler, Pd used to hang after switching audio backends. This is fixed in the Christof's scheduler_fix PR¹. I hope this gets merged soonish. Roman ¹https://github.com/pure-data/pure-data/pull/1756 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] Pduino issue
On Mon, 2023-04-17 at 15:14 -0500, Rick Snow wrote > Thank you all for your thoughts regarding this issue. Right now, I don't have anything to offer that would help you. But you seem to have established that the hardware works and it seems the problem lies in the protocol or the transport. Single messages work, but when sending them in bulk they get corrupted. In the source of comport.c, I find the line 132: #define COMPORT_BUF_SIZE 16384 Assuming this defines the buffer size for sending data from Pd to the serial line, I think it is unlikely you hit a buffer overrun. Also, it seems comport is not threaded which makes me assume that it would simply block Pd if its buffer gets full. What version of [comport] are you using? Have you tried different ones? You could try a different (lower) baud rate. For that you'd have to adapt the [arduino] abstraction and the StandardFirmata sketch. Both are set to 57600. Also, what does it need once the communications break? Do you need to power off the Arduino Mega before you can restore a working communication? Or does it help to close and open the serial port connection? 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] Pduino issue
On Tue, 2023-04-18 at 14:29 +0200, ro...@dds.nl wrote: > > in my experience using a multimeter to test the working of pins on an > Arduino > is not always giving what you expect. > i suggest to use e.g. a led to see if pins are on or off. Actually, if the pins are set to 'output' mode, I don't see a reason not to trust a multimeter (assuming it is set to measure voltage). 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] Pure Data Vanilla: [else/sfont~]... couldn't create under Manjaro Linux
On Sun, 2023-04-16 at 20:40 +0200, Linux Rouen Normandie wrote: > 1. Same issue with latest [else/sfont~] v.1.0.0 rc-7 (installed thru > Deken) than with previous versions under Manjaro Linux 22.1.0 (Arch > Linux base). [...] > 2. Error in Pd's Console: > /home/joe/Pure-Data/externals/else/sfont~.l_amd64: > libpcre.so.3: cannot open shared object file: No such file or > directory > else/sfont~ -g 0.3 > ... couldn't create @Maintainer: According to some research, Manjaro/Arch doesn't come with libpcre.so.3. The script localdeps.linux.sh included in the sfont~ sources specifically excludes '*/libpcre.so.*' (line 18), so that no local copy of the library is distributed. Maybe this pattern should be removed from 'exclude_paths', so that a local copy of libprce.so.* gets shipped with [sfont~]. @Reporter: Maybe open an issue here: https://github.com/porres/pd-else/issues 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] 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 ] > > 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 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] 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.pd 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] Pduino issue?
On Fri, 2023-04-14 at 12:37 +0200, cyrille henry wrote: > Le 14/04/2023 à 09:59, Roman Haefeli a écrit : > > On Fri, 2023-04-14 at 09:05 +0200, cyrille henry wrote: > > > > > > This sound like a problem in the serial connection, maybe the > > > arduino > > > misses some data because they are send to fast. > > > > You make it sound like it behaves like UDP where some packets are > > omitted if the link is saturated. But the serial connection is > > _serial_ > > and buffered (from what I understand) and I was assuming that data > > doesn't get randomly lost during transmission. > If you fill the buffer faster than you can empty it, at one point the > buffer will be full and then you will lose data. > you CAN lost data on serial connection. I see. Do you know how [comport] handles buffer overruns? Does it block Pd? Does it drop new data and print an error? Does it silently drop data? 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] Pduino issue?
On Thu, 2023-04-13 at 16:28 -0500, Rick Snow wrote: > I am helping someone use pd with an arduino mega. They would like to > use all of the digital output pins. I’ve used pduino in the past in > this way and not had trouble, Also with a Mega? > but I seem to be bumping into something now. What version of pduino are you using? Most current is 0.8. Also, if an older version of pduino worked fine with the Arduino Mega, what version was that? > > I started by using the arduino help patch. StandardFirmata sketch on > the Mega. Connection via usb works fine. > > I set all the pins to output by sending "pinMode 2 output” -> > “pinMode 45 output” messages to the arduino object. No errors. > > Then, I use the messages “digital 2 1” “digital 2 0” -> “digital 45 > 1” “digital 45 0” sent to the arduino object to check the pins. When > checking with a multimeter I am not able to get output from pins 2- > 7. I do get output from 8-20. Between 20-40 some pins work and > others not at all. Other pins will turn on but not turn off. What happens if you specifically send 'pinMode 45 output, digital 45 1'? Or you use any other pin that seems to be not working correctly with your setup. Also, there is 'pinState' message for querying the current state and there is the 'capability' message that triggers a report of all supported modes of all pins. So, I would like to know if the non-working pins report of themselves to support 'output' mode. Then, if you set their 'pinMode' to 'output', do they actually report their 'pinState' as 'output'? > Checking the pins using a simple blink sketch shows all the pins > working fine. Ok, so you can be sure the board is working. > Any advice would be greatly appreciate! I don't own an Arduino Mega and I don't know how well [pduino] is tested with that board. I certainly haven't tested it ever. This makes it hard for me to reproduce the problem. If you can give a hint that the problem is in the software, that would help. 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] Pduino issue?
On Fri, 2023-04-14 at 09:05 +0200, cyrille henry wrote: > > This sound like a problem in the serial connection, maybe the arduino > misses some data because they are send to fast. You make it sound like it behaves like UDP where some packets are omitted if the link is saturated. But the serial connection is _serial_ and buffered (from what I understand) and I was assuming that data doesn't get randomly lost during transmission. Of course, data still can get garbled during transmission due to unstable power, unstable physical connection and similar reasons. 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] [tof/pmenu] is the any way for setting the font size?
On Wed, 2023-04-05 at 19:59 +, Phil Stone wrote: > I just wanted to thank you for pmenu, Fred. It really fills a gap in > the Pd ecosystem. Re drop-down with configurable font-size, check [netpd-gui-dropdown]: https://github.com/reduzent/netpd/blob/main/includes/netpd-gui-dropdown-help.pd (it's vanilla and uses data structures) 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] [Deken] Wildcard does not work for 'kiosk*'?
On Tue, 2023-03-28 at 14:15 +0200, Linux Rouen Normandie wrote: > On my RPi 400 / RPi OS 11 32-bit / Pd Vanilla 0.53.1, > 'kiosk*' in 'Find externals' gives: > 'kiosk-plugin' version 0.4 iembot as of 2021-05-03. > > With Deken Preferences: > User Platform Linux-armv7-32, > and not Default Platform Linux-armv6-32. Works now for me, too. IOhannes, please tell me you fixed something. Otherwise I live in distorted reality. 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
[PD] [Deken] Wildcard does not work for 'kiosk*'?
Hi all When search 'kiosk-plugin' in 'Find externals', the plugin is listed. When searching 'kiosk*', no results are found. Using wildcards in the suggested example 'freeverb*' correctly returns 'freeverb~'. Why does the wilcard character work for freeverb~ but not for kiosk- plugin? 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] pd patch fullscreen on rpi4
On Tue, 2023-03-28 at 12:33 +0200, Simon Iten wrote: > what is the current best practice to display a pd patch fullscreen on > a raspberry pi? i have pd 0.53.1 installed. > > there was the kiosk plugin back in the days, but i could not find it > on deken... http://puredata.info/search?SearchableText=kiosk It _is_ in Deken, but you need to search for the exact name 'kiosk- plugin'. 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] A web frontend for Pd
Hey Gulio, Chair (Max?) On Thu, 2023-03-16 at 16:02 -0500, Giulio Moro via Pd-list wrote: > Here's something the Chair and Bela teams have been working on for a > few months: a proof-of-concept web interface to Pd. > > https://github.com/BelaPlatform/pure-data-web-GUI Cool! > > This leverages the refactored communication protocol effort by > Iohannes in order to obtain a "toolkit-agnostic Core<->GUI > Communication" Nice effort and impressive to see that already working. My deepest respect for those involved in developing this and in developing the new protocol used. 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] Sometimes all data-structures are redrawn
On Wed, 2023-03-08 at 00:13 +0100, Roman Haefeli wrote:
>
> As a follow-up on the matter, I identified to conditions that trigger
> a
> redraw:
>
> * Loading a patch where some scalar objects like
> [draw{symbol,number,text}]
> or [{draw,filled}{curve,polygon}] are created before the [struct]
> oject
> of the template
>
> * Loading a patch where the [struct] uses a template name
> containing $0
> like $0.fruit (!).
>
> $0 seems to be treated specially, since using $1, $2, etc. is not
> affected. Also, it doesn't help to put [struct $1 float x] into an
> abstraction [mystruct $0.fruit].
I thought I might could skip using $0 in structs by creating them as
singleton and reference that (instead of the localized $0-version) in
all instances of the abstraction. But then I noticed that I'm often
using the outlet of [struct] to detect clicks.
Assuming I have spread scalars of the same [struct] to different
canvases, is there a way to detect from the click message which canvas
the click originates from? In other words: Is there some way to
associate a pointer to a scalar with the containing canvas?
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] Sometimes all data-structures are redrawn
On Thu, 2023-03-09 at 22:14 +0100, João Pais wrote: > > > > > > Redraw times when opening patches (counted in my head): > > - 2 - 15s > > - 3 - 0s > > - 4 - also around 15s, this seems to be the reference value no matter > which other patches are opened. > > This on W10, Thinkcentre, 2x2Ghz, 16Gb Ram. Ok, thanks for testing. > My clicktracker patch (which is one GOP object) takes ages to load > now, > it wasn't like that a couple of months ago. (nothing changed in it > during this time) Interestingly, only redrawing takes long time with data structures. When loading the example patch, the scalars are drawn almost instantaneously (and they are created on the fly at loadbang). So, I suspect slower loading time is a separate issue, probably unrelated to the redrawing. You could load your patch in a previous version of Pd to check if it makes a difference. 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] Sometimes all data-structures are redrawn
On Sat, 2023-03-04 at 23:17 +0100, Roman Haefeli wrote:
>
> Sometimes when I load certain patches containing data structures, all
> data structures in all patches of an instance of Pd are redrawn.
As a follow-up on the matter, I identified to conditions that trigger a
redraw:
* Loading a patch where some scalar objects like [draw{symbol,number,text}]
or [{draw,filled}{curve,polygon}] are created before the [struct] oject
of the template
* Loading a patch where the [struct] uses a template name containing $0
like $0.fruit (!).
$0 seems to be treated specially, since using $1, $2, etc. is not
affected. Also, it doesn't help to put [struct $1 float x] into an
abstraction [mystruct $0.fruit].
Interestingly, if I load the patch without the [struct] object first,
and then create [sruct $0.fruit float x] manually, it doesn't trigger
the redraw. I'll try if I can work-around unwanted (and probably
unnecessary) redraws by dynamically creating [struct] objects instead
of loading them with the patch (as I cannot abstain from using $0).
Anyway, I hoped I could to get some insight in the matter first, but I
am more and more getting a sense that this deserves to be reported as
an issue.
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
[PD] Sometimes all data-structures are redrawn
Hey all Sometimes when I load certain patches containing data structures, all data structures in all patches of an instance of Pd are redrawn. This is barely noticeable with one single patch, but if many patches are loaded with each using many scalars, the whole redrawing process becomes unbearable. In larger netpd sessions, the process can take a few dozen seconds, depending on number of loaded instruments and probably other factors (maybe CPU speed, but none of the cores is fully loaded during the redrawing process). During the process, GUI elements like slider handles or number boxes are not updated and all DS based GUIs are not usable either. [cnv] labels are not affected (why?). The redrawing seems to cause drop outs in DSP processing. I got reports that glitches are more pronounced on Windows (or on slower computers?). I tried to figure out what exact conditions trigger such a redraw in the hope that they can be avoided. I found that the order objects of a data structure template are created matters. If [drawsymbol] was created before [struct], loading such a patch triggers the redraw. After changing the creation order, loading the patch doesn't trigger the redraw. This video illustrates it: https://netpd.org/~roman/tmp/ds-redrawing-everything.webm Apparently, there are other conditions that trigger a redraw. I tried to make sure that all [struct] objects are created last in one of my patches, but loading the patch still triggers the redraw. What are the conditions that lead to a redraw? Why are all data structures redrawn and not only the ones using scalars from the changed template? If order matters, why aren't the patches saved with the correct order? Why is the process so slow if it is apparently not CPU- bound? Is it because of the "chattiness" between GUI and core? Here another video showing how redrawing affects iemguis: https://netpd.org/~roman/tmp/ds-redrawing-affects-iemguis.webm 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] DSP crashing - PD freezes.
On Sun, 2023-02-05 at 11:45 +0100, Roman Haefeli wrote: > > And now - this sounds a bit crazy - while testing the scheduling_fix > build, the official releases (0.53-1, 0.52-2, etc.) didn't exhibit > the > high CPU usage anymore. Later, after some more testing, it happened > again though, but not with the scheduling_fix build. It's really > difficult to determine exactly what circumstances lead to the high > CPU > usage. It's as if it's possible to "taint" CoreAudio and the > scheduling_fix somehow "untaints" it. After some more testing, the more likely reason for same Pd version showing different behavior is found in the saved preferences. The issue is much more likely triggered, when enabled callbacks are saved in the preferences and thus Pd enables callbacks at loading time. Toggling DSP then will almost certainly trigger high CPU usage. Sorry for the confused reporting. Things are not trivial. 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] DSP crashing - PD freezes.
On Sat, 2023-02-04 at 18:15 -0800, Miller Puckette via Pd-list wrote: > OK, I've uploaded the fix (I hope correctly) to > msp.ucsd.edu/software.html, > as "0.53-2test1". If that seems to work for everyone I'll rename it > "0.53-2". > This build does not fix the high CPU usage of the 'pd' process I described earlier. To trigger the behavior, it seems that callbacks need to be enabled initially (saved in the preferences) and only after toggling DSP the CPU usage jumps. I can't trigger the issue as reliably when callback is disabled initially. When toggling DSP a few times with callbacks enabled, Pd sometimes hangs. The schedule_fix build seems to swallow toggling DSP and callbacks just fine. According to other reports, updating portaudio has addressed the Ventura specific behaviour (couldn't test myself, don't have access to Ventura), so probably what I describe is here is not directly related. Also, there seem to be no apparent problem when _not_ using callbacks. 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] DSP crashing - PD freezes.
On Sat, 2023-02-04 at 11:32 +0100, Christof Ressi wrote: > The callbacks option has always been broken in some way or another. > > Please try my scheduler_fix branch: > https://github.com/pure-data/pure-data/pull/1756. It would be great > to > get some feedback on this. Personally, I have been successfully I rebased your PR to current master with new portaudio version so that I get the benefits of both. Compiled and tested on Ubuntu 22.04 (amd64) and macOS 12.6.3 (had to upgrade from 10.14.6 because brew complained). Works in all tested configurations for me: * CoreAudio with and without callbacks * Jack with and without callbacks (Linux and macOS) I wasn't able to get the high CPU usage with that build. And now - this sounds a bit crazy - while testing the scheduling_fix build, the official releases (0.53-1, 0.52-2, etc.) didn't exhibit the high CPU usage anymore. Later, after some more testing, it happened again though, but not with the scheduling_fix build. It's really difficult to determine exactly what circumstances lead to the high CPU usage. It's as if it's possible to "taint" CoreAudio and the scheduling_fix somehow "untaints" it. After all, the scheduling_fix doesn't seem to cause trouble and seems work ewll. Will test again with Miller's "0.53-2test1" (that should be equivalent to my scheduling_fix build) and report back. Many thanks for the pointer, Christof, and many thanks to all others involved in tackling backend issues. 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] DSP crashing - PD freezes.
On Sat, 2023-02-04 at 10:04 +0100, Dan Wilcox wrote: > Do you have callbacks enabled? If so, disable the checkbox in the > audio dialog. So what's the deal with Callbacks on CoreAudio/macOS? On all the combinations of Pd version and macOS version I tried, funny things happen with callbacks enabled. Are there situations when using callbacks (on CoreAudio) bring any benefit? If so, what are those situations? I think I understand how callbacks affect the interaction between Pd and JACK when using JACK, but it's a bit opaque to me what their purpose is when using CoreAudio. On Jack, using callbacks makes Pd not add any additional latency on top of JACK's own latency. So, which latency critical applications, I was hoping to affect latency in similar way by using callbacks with CoreAudio. Once I touch the callback toggle, I see Pd's CPU usage jumping to 100% and there is no way to make go back. Even when I send `@callback 0` using the mediasettings library, things go havoc. Once in that state, it cannot be undone by toggling callback (or sending '@callback 1, @callback 0' to [audiosettings]). Only a restart of Pd helps. Is it expected that Pd uses 100% of core with callbacks enabled? Or should I report a bug? What's the supposed benefit of that toggle? 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] DSP crashing - PD freezes.
On Mon, 2023-01-30 at 20:03 +0100, Denis Połeć wrote: > > Does anyone else experience this issue? I have access to macOS 10.14.6 and I experience issues with CoreAudio, too (none with JACK, though). > I have tried older versions, but I am getting the same result. Me too: 0.53-1, 0.52-2, 0.51-4, 0.50-2 > Is this an issue with Ventura? Can someone reproduce this? I'm not sure what exactly triggers it, but after touching the audio dialog, CPU usuage of pd process jumps to 100%, but aside from fan noise, Pd seems to work still normally. It takes quite long to shut down, once it is in that state. It appears the behaviour is reladed to using callbacks (checkbox in the audio dialog). When callbacks are disabled, things seem to work normally and CPU usage stays low. However, with callbacks turned on CPU usage jumps to 100% and Pd freezes after turning DSP off. I believe I had one incidence where restarting Pd after having saved audio settings with callbacks disabled still resulted in high CPU usage. I purged the configuration files org.puredata.* in ~/Library/Preferences and saved audio settings again with callbacks disabled. 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] [PD-announce] PuREST JSON 2.0.0 "Medea" released
On Tue, 2023-01-31 at 12:31 +0100, Thomas Mayer wrote: > Hi Tobias, > > On 31.01.23 08:47, KHM Mail wrote: > > when using the external, [rest], [oauth] and [urlparams] are not > > working. > > Error shows: > > > > Library not loaded: '/opt/homebrew/opt/json-c/lib/libjson- > > c.5.dylib' > > Referenced from: > > '/Users/XXX/Documents/Pd/externals/purest_json/rest.pd_darwin' > > Reason: tried: '/opt/homebrew/opt/json-c/lib/libjson-c.5.dylib' (no > > such file), '/usr/lib/libjson-c.5.dylib' (no such file) > > As Roman has mentioned, there is version 2.0.1 only for Mac OS, > because > 2.0.0 did not include libcurl in the package > (https://github.com/residuum/PuRestJson/issues/76), but that is not > the > case here. > > It looks like the libraries are not linked correctly, because it > should > search for the dylib file first in the same folder, but that is not > the > case here. > > As I do not own or have access to a Mac, maybe this has something to > do > with security hardening in current Mac OS X versions, try run Pd with > the -verbose flag, and look for output on the Pd console. > > Are there lines containing the following: > "file system relative paths not allowed in hardened programs". > > See also the conversation about this bug report: > https://github.com/residuum/PuRestJson/issues/51 The included libraries are x86_64 only. Even if the the externals are multiarch, they won't work on arm64. 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] [PD-announce] PuREST JSON 2.0.0 "Medea" released
On Tue, 2023-01-31 at 08:47 +0100, KHM Mail wrote: > Hi Thomas and list, > > when using the external, [rest], [oauth] and [urlparams] are not > working. > Error shows: > > Library not loaded: '/opt/homebrew/opt/json-c/lib/libjson-c.5.dylib' > Referenced from: > '/Users/XXX/Documents/Pd/externals/purest_json/rest.pd_darwin' > Reason: tried: '/opt/homebrew/opt/json-c/lib/libjson-c.5.dylib' (no > such file), '/usr/lib/libjson-c.5.dylib' (no such file) > I see there is a version 2.0.1 available only for macOS (x86_64 and arm64). Without having looked at your problem in detail, you tried that version? This looks like something has been fixed specifically for macOS. https://deken.puredata.info/library/purest_json 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] dwt~
On Mon, 2023-01-16 at 10:23 +0100, Paul Pignon wrote: > Just reinstalled Debian 11 (got really wonky), now missing lots of > pd stuff. > Need dwt~, not in creb anymore, though dwt~help.pd is there, oddly > enough. Add: [declare -lib creb] to your patch in order to load the creb library. (Probably your patch does something like [declare -stdlib creb], but this like doesn't work anymore with the default path Deken installs into). 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
[PD] [PD-announce] New versions of [command], [jackpatch], [mp3cast~] on Deken
Hey all The following new or updated externals are available on Deken: * command v0.4 * add 'env' method to set environment variables * add '-s' flag for synchronous (blocking) mode of operation * jackpatch v0.2 * forked from jackx * manages and queries jack connections * mp3cast~ v0.6 * add 'timeout' method for limiting connection time * add 'icy-title' method for updating Icecast2 song title Supported platforms: * Darwin-amd64-32 * Linux-aarch64-32 * Linux-amd64-32 * Linux-armv7-32 * Linux-i386-32 * Windows-amd64-32 (not command) * Windows-i386-32 (not command) Comes later: * Darwin-arm64-32 (when I get access to an M1 MacBook again. If someone else wants to jump in, feel free) Roman signature.asc Description: This is a digitally signed message part ___ Pd-announce mailing list pd-annou...@lists.iem.at https://lists.puredata.info/listinfo/pd-announce ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Basic send historical issue 32 bits / 64 bits
On Tue, 2022-12-20 at 10:43 +0100, IOhannes m zmoelnig wrote: > On 12/20/22 08:10, Lucas Cordiviola wrote: > > hi, > > > > you should *not* convert the list to a symbol: > > totally. > [l2s] just adds a lot of overhead, for no benefit. The reason it used to work even with [l2s] is unrelated to 32bit vs. 64bit. Earlier versions of Pd didn't escape spaces in symbol atoms, so when the symbol got out of Pd, i.e. written to file or sent through network, the symbol containing spaces became a list of symbol atoms. 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] default colors of iemguis (was: some gui objects with grey background in help patches?)
> On Tue, 29 Nov 2022, 02:56 Alexandre Torres Porres, > wrote: > > Em seg., 28 de nov. de 2022 às 05:05, Roman Haefeli > > escreveu: > > > On Mon, 2022-11-28 at 02:58 -0300, Alexandre Torres Porres wrote: > > > > For the record, I just realized default colors of iemguis is > > > > not "pure white" (...) > > > > it is "FCFCFC" (...) This is not a regression, it's the same in > > > > pd 0.48, > > > > > > > > I don't know why or where that happens in the code > > > > > > I haven't checked the code, but the old encoding allowed for only > > > 6 > > > bits per channel. Assuming the two least significant bits are set > > > to 0, > > > FC is the highest value possible in that scheme > > > > > > 0xFC = 0b 1100 > > > > > > > > > It's much simpler than that. Default color is explicitly set and > > defined as "0xFCFCFC" in g_all_guis.c, more specifically here: > > > > https://github.com/pure-data/pure-data/blob/06ecc41f42059bfe02081e4738ed21f6bcd0eac9/src/g_all_guis.c#L1030 > > > > default "front" and "label" colors are also set there as black. > > > > [cnv] has different default colors specified in its code (0xE0E0E0 > > for background and 0x404040 for label); On Tue, 2022-11-29 at 07:55 +0100, Simon Iten wrote: > i think what roman is trying to say is that the color was indeed > displayed as white back in the days (in 6bit) and the two trailing > zeros are there because the value was shifted two positions to the > left (<< 2 binary operation) to align with 8bit variables more > conveniently... (or maybe i misunderstood completely) I thought the value #FCFCFC comes from the 6bit encoding scheme and Alex pointed out that this value is hardcoded as the default value. Now I think, this is the hard-coded default value exactly because of the old 6bit encoding scheme. If the initial values was 0xFF, you wouldn't have been able to get back to that value once you changed colors in the properties. From what I remember, the iemguis never were exactly white and you couldn't make them white, at least not with the RGB dialog. Roman ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] mp3cast~ oggcast~ and alternatives
On Mon, 2022-11-28 at 09:46 +0100, jack wrote: > > Nice to see that you are involved in maintening [mp3cast~]. I have some stuff depending on [mp3cast~], so I'm somewhat invested. However, I'm not a seasoned C coder and the amount of time I dedicate to externals maintenance fluctuates a lot. Still, issues have a better chance to be addressed when reported. > I opened the two issues on Github. Thanks! Roman ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] some gui objects with grey background in help patches?
On Mon, 2022-11-28 at 02:58 -0300, Alexandre Torres Porres wrote: > For the record, I just realized default colors of iemguis is note > "pure white" as we've been discussing. > > Sure it is "witheish", more precisely, it is "FCFCFC" instead of > "FF" (pure white). So a very light grey color (99% brightness in > the grey scale). This is not a regression, it's the same in pd 0.48, > which I also tested. > > I don't know why or where that happens in the code I haven't checked the code, but the old encoding allowed for only 6 bits per channel. Assuming the two least significant bits are set to 0, FC is the highest value possible in that scheme 0xFC = 0b 1100 Roman ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] mp3cast~ oggcast~ and alternatives
On Mon, 2022-11-28 at 00:05 +0100, jack wrote: > > > Unfortunately, [mp3cast~] freeze Pd : > - start a stream to icecast2 server > - cut your network connection > => Pd freeze Please open an issue at: https://github.com/pd-externals/mp3cast/issues > and it not allow to inject tags during stream to change the title or > artist name during stream. +1 Yeah, I think this would be a nice feature. Please add another issue about this. In the meanwhile, you can also use the following abstraction based on purest_json: https://netpd.org/~roman/tmp/icecast_update_song.zip Roman ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] http get/post request in pd. how to?
On Thu, 2022-11-24 at 22:00 +0100, KHM t.hartmann wrote: > Hello List, > > is there a way to make http requests (get/post) in Pd? > In max it can be done with the [dictionary] for composing the request > header/body als JSON objects, then > send it as a request with [maxurl]. Check purest_json. It is available through Deken. Roman ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] some gui objects with grey background in help patches?
On Tue, 2022-11-22 at 13:32 +0100, Max wrote: > I wanted to add my voice here to say that I like the work Alex did > and > appreciate the many many bug fixes, clarifications, the drive for > consistency and readability across the help patches. I agree with Max and Dan here. I appreciate the work done by Alex and I think it's a clear improvement. On the specific issue of colors, I'm indifferent. However, he's the one who did the work and who had to decide on many little things. It's in the nature of such proceedings that not everyone agrees on the every last detail. My impression is opinions on the color issue are mixed and not clear-cut, thus I doubt time on making everything black-white again is well spent. Roman ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] cannot find ggee external - I need [shell] or [command]
On Fri, 2022-11-11 at 16:14 +0100, IOhannes m zmölnig wrote: > Am 11. November 2022 16:06:22 MEZ schrieb Roman Haefeli > : > > On Fri, 2022-11-11 at 14:22 +, mick mengucci wrote: > > > > > > I also saw that Alexandros suggests [command] but which external > > > do I > > > need installed? > > > > Deken provides a command external for Linux-armv7-32. Have you > > tried > > that? Or are you using a 64bit Raspberry Pi? > > > You can always just install the pd-ggee package that comes with your > system: > > $ apt-get install pd-ggee Yeah, though I wouldn't recommend using [shell] for new projects. It is really limited and [command] was specifically written to overcome the shortcomings of [shell]. IMHO, the only use-case for [shell] is running old projects that already use it. Roman ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] cannot find ggee external - I need [shell] or [command]
On Fri, 2022-11-11 at 14:22 +, mick mengucci wrote: > > I also saw that Alexandros suggests [command] but which external do I > need installed? Deken provides a command external for Linux-armv7-32. Have you tried that? Or are you using a 64bit Raspberry Pi? 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] Biased waveform display?
On Tue, 2022-10-11 at 13:51 +0200, jayrope wrote: > Thank you both IOhannes and Jaime, two excellent suggestions (when i > work on a proper laptop at least). > > Still, both methods seem to require simultaneous writing of same > audio > twice. > So in order to escape the obvious RAM/data hogging: > What would be needed to add a switchable display feature to a graph > otherwise, giving a user an opportunity to switch from linear display > to > inverse exponential? It sounds like an extra line or two of object > code > to me somehow. > > Asking out of curiosity. I've no idea how to code that myself. Here is another idea (not sure if it's been mentioned yet): Store the audio in the display format: Apply a function while recording, and apply the inverse function while playing. I thought about [pow 0.25] for recording and [pow 4] for playback first, but this will flip the negative parts of the waveform to the positive range. Maybe you come up with something that actually works. Roman ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd 0.53-0test2 scrollers
On Mon, 2022-10-24 at 11:36 +0200, IOhannes m zmölnig wrote: > On 10/24/22 04:35, Miller Puckette via Pd-list wrote: > > OK, I think the scrollbar test is working now. However, all the > > IEMGUIs > > still make empty strings above themselves causing unnecessary > > scrollbars to > > appear. I think the fix should be either to not draw them at all > > (that > > would be best?) or to put them back where they were in 0.52. > > > > > i'm definitely favouring the first solution (not drawing at all). Me too. Oh my I'd rather do not think about the time I spent relocating empty labels in order to suppress scrollbars in my patches. It never occurred to me to open an issue about it :-( Roman ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] looking for a simple eq
On Mon, 2022-09-26 at 18:25 +0200, Jakob Laue wrote: > Actually I just need simple low-cutting https://github.com/reduzent/netpd-instruments/blob/main/abs/fl_reshighpass_coeff.pd > from low to high frequencies and/or high-cutting from high to low https://github.com/reduzent/netpd-instruments/blob/main/abs/fl_reslowpass_coeff.pd Those two generate the coefficients that can be fed to [biquad~]. > . A visual representation would be great. The same coeffs that are fed to [biquad~] can be used to plot the frequency response (and phase response) with: https://github.com/reduzent/netpd-instruments/blob/main/abs/fl_filterplot.pd I don't deserve credit for them. They are based on abstractions created by Mike Moser-Booth. Here is what the filterplot looks like: https://www.netpd.org/fl-rhip.png (screenshot of: https://github.com/reduzent/netpd-instruments/blob/main/abs/fl-rhip.pd ) Roman ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [vstplugin~] on a RPI 3 ? ...
Hi Oliver On Tue, 2022-09-20 at 12:28 +0200, oliver wrote: > > i'm trying to install [vstplugin~] on a RPI 3+ > > (PD version is 0.54.1 - raspbian buster) Wow, can I have that version too? What does it feature? :-) > > deken doesn't find any files compiled for ARM. > trying "apt install pd-vstplugin~" doesn't work either Usually, deb package names omit the ~. But there is also no 'pd- vstplugin' in Debian/Raspbian/Raspberry Pi OS. > > Do i have to try to compile it myself ? I tried and failed at: /home/pi/pd-src/vstplugin/vst/Search.cpp:77:4: error: #error "CPU architecture not supported (yet)" 77 | #error "CPU architecture not supported (yet)" |^ > Or do i need a newer system ? Probably not. I wonder if it is possible at all to compile it on archs that are not explicitly supported by the VST SDKs. Roman ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] mypdwindow-plugin not working in Windows 11
Maybe the problem isn't the switch from Windows 10 to 11, but rather
the plugin is not loaded on the other box?
Set Log-Level in the Pd window to "3 debug". You should see a message
like:
Loading plugin: /home/roman/Pd/externals/mypdwindow-plugin.tcl
If this is not shown, then make sure that paths are configured
correctly in "Preferences" -> "Path".
Roman
On Thu, 2022-09-08 at 13:04 +0200, ro...@dds.nl wrote:
> hi,
> (Pd 0.52.2 Windows 10/11)
> i'm using the mypdwindow-plugin.tcl to have fixed
> position/dimensions of the pd-console.
> this is the content:
> if {[winfo exists .pdwindow]} {
> wm geometry .pdwindow =500x800+0+0
> }
>
> in Windows 10 it worked perfectly.
> now in Windows 11 not at all: i get the standard Pd behaviour.
>
> as far as i know Tcl/Tk is not included in Windows itself.
> tclsh in a command window is not recognized by Windows, not in W10 or
> in W11.
> so, there cannot be a version conflict and the behaviour of tcl
> commands in connection with Pd should be the same.
>
> of course it's not more then a nuisance,
> but i would like to understand what's happening.
>
> rolf
>
> ___
> 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] using 'audio-setapi' without dialog popping-up
On Thu, 2022-07-07 at 12:09 +0200, IOhannes m zmoelnig wrote: > On 7/7/22 11:40, Roman Haefeli wrote: > > Hi all > > > > Is there a way to change audio backends programmatically (with > > 'audio- > > setapi' message or any other) _without_ the audio settings dialog > > popping up? Or is there a way to hide it again after it pops up? > > > use the [mediasettings] library. > > it is *exactly* for this usecase (as in: it will internally use > 'audio-setapi' and what not, but completely hide this from the user). Great! It is simple to use and works smoothly. BTW: I need a version compiled for d_arm64. If I succeed, should I upload it to Deken or do you prefer to do that yourself (or to let the iembot do it)? Roman ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] using 'audio-setapi' without dialog popping-up
Hi all Is there a way to change audio backends programmatically (with 'audio- setapi' message or any other) _without_ the audio settings dialog popping up? Or is there a way to hide it again after it pops up? Thanks, Roman ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] accountant's delight: deken v0.9
On Sat, 2022-05-21 at 17:04 -0300, Alexandre Torres Porres wrote: > Yay, nice , looks pretty awesome, powerful and clean, congrats! > > I'd just like to know how to use some of the features, like: Just try it out and you will see. > - quick link from a package to it's deken homepage (which features > objectlists and more) right-click on package -> open package webpage > - simple selection of multiple packages 1. Search for "iemlib iemnet osc slip" 2. Shift-click all the packages you intend to install > - tooltip Hovering a package with the mouse shows the package's full name in a tooltip. > - balloons 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] Deken-Server functional?
On Mon, 2022-05-16 at 10:54 +0200, Antoine Rousseau wrote: > OK I did it. > I checked, it works for both 16.04 and 20.04! Yeah, thanks. Works for me on Ubuntu 22.04 and Debian Bullseye, too. I'll re-upload more compatible version for Linux-i386-32. I don't have a Linux-armv7-32 machine older than Debian Buster, though. 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] Deken-Server functional?
On Sun, 2022-05-15 at 22:23 +0200, Antoine Rousseau wrote: > > .. btw the binary doesn't load on my Ubuntu16.04 machine: > /home/---/pd-externals/mp3cast~/mp3cast~.l_amd64: /lib/x86_64-linux- > gnu/libm.so.6: version `GLIBC_2.27' not found (required by /home/--- > /pd-externals/mp3cast~/amd64/libmp3lame.so.0) > > But after installing libmpg123-dev and libmp3lame-dev, recompiling > did the trick! Thanks for testing and for the report. I decided Debian Buster as my build machine because of another external that has a dependency that doesn't compile on older releases. The current builds should work with Ubuntu 20.04 and upwards and Debian 10 and updwards. But there is no reason for the mp3cast~ external not to be compiled on an older machine. The oldest I have available is Debian 9. I think that would cover Ubuntu 18.04 and upwards. While 18.04 still has support, 16.04 has not. Maybe you could upload your 16.04 build, at least for Linux-amd64-32? That would gives us the greatest coverage. If you do, make sure to bump the version, so that yours gets priority. I suggest '0.5-1' (like Debian's revision number). Roman > Le dim. 15 mai 2022 à 22:11, Antoine Rousseau a > écrit : > > I can list them here, from both Pd's interface and > > https://deken.puredata.info/search.html?libraries=mp3cast%7E== > > > > > > > > > > Le dim. 15 mai 2022 à 21:35, Roman Haefeli a > > écrit : > > > Hey all > > > > > > A few days ago, I uploaded with Deken the new package mp3cast~ > > > for > > > various platforms. The files are online, but "Find external" -> > > > "Search" doesn't list them. > > > > > > I'm not sure how the inclusion works, but either I did something > > > wrong > > > or the regular scanning for new uploads stopped working. > > > > > > https://puredata.info/Members/rdz/software/mp3cast%7E/0.5/ > > > > > > @IOhannes, thanks for looking into it. > > > > > > Roman > > > ___ > > > Pd-list@lists.iem.at mailing list > > > UNSUBSCRIBE and account-management -> > > > https://lists.puredata.info/listinfo/pd-list 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] Deken-Server functional?
On Sun, 2022-05-15 at 22:11 +0200, Antoine Rousseau wrote: > I can list them here, from both Pd's interface and > https://deken.puredata.info/search.html?libraries=mp3cast%7E== Oh my, a classic case of PEBCAK. I searched for 'mp3cast' (without ~) and I was one of the people who voted for showing exact matches only! Sorry for the noise. Roman > Le dim. 15 mai 2022 à 21:35, Roman Haefeli a > écrit : > > Hey all > > > > A few days ago, I uploaded with Deken the new package mp3cast~ for > > various platforms. The files are online, but "Find external" -> > > "Search" doesn't list them. > > > > I'm not sure how the inclusion works, but either I did something > > wrong > > or the regular scanning for new uploads stopped working. > > > > https://puredata.info/Members/rdz/software/mp3cast%7E/0.5/ > > > > @IOhannes, thanks for looking into it. > > > > Roman > > ___ > > Pd-list@lists.iem.at mailing list > > UNSUBSCRIBE and account-management -> > > https://lists.puredata.info/listinfo/pd-list 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
[PD] Deken-Server functional?
Hey all A few days ago, I uploaded with Deken the new package mp3cast~ for various platforms. The files are online, but "Find external" -> "Search" doesn't list them. I'm not sure how the inclusion works, but either I did something wrong or the regular scanning for new uploads stopped working. https://puredata.info/Members/rdz/software/mp3cast%7E/0.5/ @IOhannes, thanks for looking into it. 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] two sliders on top of each other (XY-Controller)?
On Thu, 2022-05-12 at 14:07 +0200, Christof Ressi wrote: > > > but more interestingly it is the lower > > of the two slider that receives the mouse clicks while the upper is > > visible. Is this intentional? > > This is a fundamental issue with Pd's GUI. The first matching object > in > the list receives the event. Since objects are drawn in ascending > order, > the backmost object will receive the event. I find this very > annoying, I've learned to appreciate it as a feature. It's counter-intuitive, because one would expect that what is seen can be manipulated. I see that aspect. But on the other hand, the current behavior allows for a lot of neat tricks to create fancy GUI widgets. 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] filter stability
On Wed, 2022-04-27 at 11:27 -0300, Alexandre Torres Porres wrote: > I guess I can get the coefficients and derive an overall gain > parameter. I got objects in ELSE that do that [coeff2pz]. But if it > also depends on the frequency I should calculate this all of the time > which doesn't seem reasonable. Maybe just keeping a safe 0.5 q is > fine... > > You know, using something like lop~ is pretty stable, I am now > wondering if I should just use if for the sake of simplicity and > efficiency as well. Do I really need a 6db decay per octave instead > of 3db? What do you people think? Isn't a low steepness in the filter in the feedback loop desired anyway? Me thinks a low steepness means the change in timbre happens more slowly which - I imagine - would sound nicer than a sudden 'tziewhh'. 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
[PD] Deken filename too long for certain filesystems (ecryptfs on ext4)
Hey all While trying to install the most recent version of ELSE, Deken simply reported: "Download failed". I then tried to download with wget which succeeded, but the resulting file was named (125 characters): else[v1.0-0_beta45_with_live_electronics_tutorial](Darwin-amd64-32)(Darwin-i386-32)(Linux-amd64-32)(Linux-arm64-32)(Linux-ar The original filename is much longer (186 chars): else[v1.0-0_beta45_with_live_electronics_tutorial](Darwin-amd64-32)(Darwin-i386-32)(Linux-amd64-32)(Linux-arm64-32)(Linux-armv6-32)(Linux-i386-32)(Windows-amd64-32)(Windows-i386-32).dek While many filesystems use a limit of 255 chars for names, mine is bit more limited. I encrypted my home folder with ecryptfs which is a userspace filesystem on top of ext4. Because encrypting the filename requires extra space, the limit of ecryptfs for filenames is lower than the one of the underlying filesystem (which is ext4 in my case). I think having a lower limit than the common 255 characters is silly. I don't think that Deken packages should assume a smaller filename limit than 255. However, we see that the above example is not that far from that (support for a few additional archs or double-precision could reach it). Also, I wanted to share my experience. Maybe it has an impact on the recent external double-precision file extension discussion. 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] Pd 52.2 different font in console?
On Sat, 2022-04-09 at 15:48 -0300, Alexandre Torres Porres wrote: > > The issue now is a different one and it is that the display seems to > be different. Before, a font size of 12 did fit nicely, now it > doesn't. At least that's what I perceived, but I might be wrong and > was actually checking here. My concern is that maybe the rendering > changed or something, and when this issue came up here I thought I'd > bring it up to see if there could be a relation. > > Here are some screenshots, left is 0.52-1, right is 0.52-2, left has > font size = 12, first we compare to the right with font size = 12, > then font size = 10. I'm bear some of the blame for this. I found it odd that the Pd console doesn't use monospaced font (since consoles usually use a monospaced font) and opened an issue: https://github.com/pure-data/pure-data/issues/1558 Then it became clear that the font was supposed to be monospaced all along but it wasn't implemented properly. This issue was tagged 'bug' and got fixed quickly by IOhannes. 0.52-2 was the next release after this got merged. @Alex: I see how this breaks the appearance of the ELSE banner in the console and I'm sorry for that. I reckon it uses some ASCII-art which doesn't work well with non-monospaced fonts. At least, in the future you'll get a reliable look. There are other external banners that use ASCII-art-like decorations. Personally, I find it often easier to follow the printed messages of a patch when the font uses a consistent width. Re bigger: I imagine what is a comfortable window size is dependent on the output medium. When working on an external 4K monitor, I keep dragging many of Pd's windows larger all the time, especially the file dialog, which to me has a ridiculously small default size. I mean: I find the font size OK, but the Pd window too narrow. For my local install, I changed it to 700x400 in tcl/pdwindow.tcl:395 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] [PD-announce] Most recent Pd packaged for Ubuntu (and derivatives)
On Wed, 2022-04-06 at 15:54 +0200, Max wrote: > I think this might be related: > > https://github.com/pure-data/pure-data/pull/1364/commits Yeah, I think so, too. But apparently that is not all. We need to create also a metadata file describing the application. There is web form for this: https://www.freedesktop.org/software/appstream/metainfocreator/#/guiapp I created the attached xml with it. Roman (I haven't checked whether it's such a file that IOhannes added recently to the salsa repo. But I will) > On 06.04.22 15:29, IOhannes m zmoelnig wrote: > > On 4/6/22 13:03, Kaj Ailomaa wrote: > > > Any universal packaging changes should be done in Debian > > > directly, > > > though. > > > > i've now added some metadata to the Debian packages (but none are > > uploaded yet). > > > > if somebody (e.g. roman), wants to test them, they can grab my > > changes > > from https://salsa.debian.org/multimedia-team/pd/puredata/ > > > > and see whether this fixes anything. > > > > (please don't upload any packages build from the repository yet; > > but > > feedback is of course welcome) > > > > gfmdas > > 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 org.puredata.pd.metainfo.xml Description: XML document 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] [PD-announce] Most recent Pd packaged for Ubuntu (and derivatives)
Yesterday, I discovered that you cannot install "Pure Data" with the default graphical "Software" manager on Ubuntu status. It looks like the vanilla (non-terminal) way of installing software on Ubuntu (at least 20.04) is the graphical application gnome-software. gnome-software works like an app store and apparently also manages snaps and other formats. However, the list of available applications is curated and "Pure Data" is not part of it. It doesn't appear in the section "Audio & Video" nor in the section "Development tools". Even specifically searching for "Pure Data" or "puredata" doesn't yield any results. That's not exactly good advertisement! People either have to install 'synaptic' - which is a graphical frontend for apt - or use the terminal to the install the 'puredata' package. Yet, I'm not sure how this is addressed. But I think we should address it. Someone on #ubuntu posted this link when I asked about the process of including software in the curated list: https://www.freedesktop.org/wiki/Distributions/AppStream/ Roman On Wed, 2022-04-06 at 09:32 +0200, Robert Grah wrote: > Gerat news! Thank You! > > Am Di, 05 Apr 2022 23:35:37 +0200 Roman Haefeli < > reduz...@gmail.com> schrieb > > Hi > > > > I added the current version of Pure Data to my personal package > archive > > (PPA), so that it is finally possible to get a recent version of > Pd on > > Ubuntu without compiling. > > > > Kudos goes to IOhannes who maintains the puredata package on > Debian and > > who makes sure that the most recent release of Pd is available in > the > > backports repository. His work enabled me to just¹ get his package > > sources and push them to my PPA. > > > > I also rewrote the "How to install on Debian/Ubuntu" FAQ page on > > puredata.into who was referring to the retired apt.puredata.info > repo > > and Pd-extended. > > > > You find instructions on how to get the most recent version of Pd > on > > Debian and on Ubuntu here: > > > > https://puredata.info/docs/faq/debian > > > > > > Roman > > > > > > > > ¹well, a little work was necessary... > > ___ > > Pd-announce mailing list > > pd-annou...@lists.iem.at > > https://lists.puredata.info/listinfo/pd-announce > > > > > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list 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
[PD] [PD-announce] Most recent Pd packaged for Ubuntu (and derivatives)
Hi I added the current version of Pure Data to my personal package archive (PPA), so that it is finally possible to get a recent version of Pd on Ubuntu without compiling. Kudos goes to IOhannes who maintains the puredata package on Debian and who makes sure that the most recent release of Pd is available in the backports repository. His work enabled me to just¹ get his package sources and push them to my PPA. I also rewrote the "How to install on Debian/Ubuntu" FAQ page on puredata.into who was referring to the retired apt.puredata.info repo and Pd-extended. You find instructions on how to get the most recent version of Pd on Debian and on Ubuntu here: https://puredata.info/docs/faq/debian Roman ¹well, a little work was necessary... signature.asc Description: This is a digitally signed message part ___ Pd-announce mailing list pd-annou...@lists.iem.at https://lists.puredata.info/listinfo/pd-announce ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] how to write different types to [text]
On Tue, 2022-03-29 at 10:55 +0200, Christof Ressi wrote: > > How am I supposed to know that > > 1 2 3, a b c, foo bar baz; > actually counts as 3 "lines"? > > I think a more proper term would be "message". I think the > documentation has to be improved. @porres to the rescue!! :-) +1 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] how to write different types to [text]
On Sun, 2022-03-27 at 22:39 +0200, Christof Ressi wrote: > On 27.03.2022 18:22, Christof Ressi wrote: > > I guess you should be able to do [3 3( -> [text get] to get the > > second > > sublist, but [3 4( -> [text get] should probably trigger an > > out-of-range error. > > I meant to write [0 3 3( -> [text get] and [0 3 4( -> [text get]... > > Another side note: it would be nice if a negative field count for > [text > get] would output all fields up to the next seperator (comma or > semi). I agree and it does so already. 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] how to write different types to [text]
On Sun, 2022-03-27 at 18:22 +0200, Christof Ressi wrote: > > There is no way to get the rest of the message. I think [text get] > > could simply output all sublists consecutively. By checking the > > right outlet you know if a message spans a whole line (= 0), or is > > part of a comma seperated list of messages (= 1). > > To be more precise: it should output all sublists when you request a > *whole line* (field number = -1). > > If you have the following text: > > 1 2 3, foo bar baz, 5 6 7; > [0( -> [text get] would output "1 2 3" (type 1), "foo bar baz" (type > 1) and "5 6 7" (type 0) [0( now returns only '1 2 3'. [1( accesses 'foo bar baz', and [2( '5 6 7' (type 0). > But how would you access individual sublists? There is no need to access _sublist_ since lists of either type are accessed and counted the same. I think, this aspect of accessing messages is already consistent and complete. You cannot _create_ lists ending with a comma, however. I propose a 'type' inlet in [text set] and [text insert], just for completeness and consistency. [11 12 13( [2( [1( <- type | / / [text insert ] with above text buffer example would create: 1 2 3, foo bar baz, 11 12 13, 5 6 7; Roman > I guess you should be able to do [3 3( -> [text get] to get the > second sublist, but [3 4( -> [text get] should probably trigger an > out-of-range error. > > But we do not know the indices and sizes of the individual sublists! > > Maybe [text size] could have an extra outlet to provide that > information? Maybe output a list of indices? > > This definitely needs a bit of thinking... > > Christof > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list 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] how to write different types to [text]
On Sun, 2022-03-27 at 18:04 +0200, Christof Ressi wrote: > On 27.03.2022 11:01, Roman Haefeli wrote: > > On Sun, 2022-03-27 at 01:10 +0100, Christof Ressi wrote: > > > In my experience, commas in [text] are broken... Best not to use > > > them > > > :-) > > > > What is the purpose of 'type' in [text] then? I find your advice of > > not > > using a feature because it is broken - frankly - disconcerting. If > > it's > > broken, then it ought to be fixed. > > Sure. I was a bit tongue-in-cheek :-) > > Currently, [text get] just strips all atoms after the first comma and > outputs 1 (= colon) as the type. There is no way to get the rest of > the message. This is not what I experience. Commas don't wrap, so what comes after a comma is still on the same line. However, [text get] and [text size] are consistent in that they consider messages and not lines. ``` eins; zwei; drei, vier; fuenf; ``` [text size] returns 5. [2(-[text get] returns 'symbol drei'. The message after that is accessed with [3(-[text get]. > I think [text get] could simply output all sublists consecutively. I think it does exactly that. > By checking the right outlet you know if a message spans a whole line > (= 0), or is part of a comma seperated list of messages (= 1). > > Another issue that you have mentioned is that we can't *set* lines > that include actual commas. One simply solution could be to add a > flag to [text set] that interprets the list as *escaped* text, just > like [text fromlist] > > The only case where commas do already work is in [text sequence -g]: > > foo 1 2 3, bar baz > This will indeed send the messages "1 2 3" and "bar baz" to > destination "foo". > > > Apparantly, FUDI uses both, commas and semicolons. In message > > boxes, > > they have a different meaning. The selector of a message after a > > semicolon is considered a send symbol. Everything after a comma i > > considered simply a message. > > comma *atoms* always have that meaning. It just appears to be > different depending on which level you look at it: "patch file" VS > "patch" > > A Pd patch files is really just a sequence of messages, and > consequently it can make use of comma atoms as a shortcut, just like > in your example: > > > #X floatatom 26 77 5 0 0 0 - - -, f 5; > > That's really the same as: > > #X floatatom 26 77 5 0 0 0; > #X f 5; That's really interesting. That's exactly how I "worked-around" the issue a few years ago and today I was thinking: 'What the hell am I doing here? That looks broken'. Indeed, the effect of both examples is the same. So, if those are equivalent, then I don't actually need commas and the issue I am trying to address is moot. > (And you're right that it causes troubles when trying to parse Pd > patch files within Pd.) Pd seems to parse: #X floatatom 26 77 5 0 0 0; #X f 5; just fine. > When comma atoms are used inside a patch (e.g. in message boxes, > [text define], etc.), they have to be escaped in the Pd patch file: No, when editing patch files, I don't want escaped commas. I'd like to preserve their meaning. Adding esacped commas is easy (or at least, I think so), whereas adding un-escaped commas are impossible (but not strictly necessary, as you can get the same meaning by other means). > #X msg 39 327 vis 0 \, vis 1; > (In [text] it appears as a symbol atom, so it can be set and > retrieved with [text set] and [text get].) > > Here's a combination of these two layers of meaning: > > #X msg 49 252 foo 1 2 3 \, 5 6 7, f 20; > The first (escaped) comma belongs to the message box, but the second > one will just send the following message to #X (= the current > object). My initial question was about how to do the second case: Creating a message that _ends_ with a comma. Not: Creating a message that _contains_ a comma. The former is achieved with: [list sechs \, sieben( | [text set] 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] how to write different types to [text]
On Sun, 2022-03-27 at 01:10 +0100, Christof Ressi wrote: > In my experience, commas in [text] are broken... Best not to use them > :-) What is the purpose of 'type' in [text] then? I find your advice of not using a feature because it is broken - frankly - disconcerting. If it's broken, then it ought to be fixed. Apparantly, FUDI uses both, commas and semicolons. In message boxes, they have a different meaning. The selector of a message after a semicolon is considered a send symbol. Everything after a comma i considered simply a message. In texts, the distinction was not clear to me, but it seems the Pd patch format itself uses both: #X floatatom 26 77 5 0 0 0 - - -, f 5; the message 'f 5' defines the width of the number box. I'd like to be able to modify Pd files with [text], since I believe both [text] and the Pd parser use the same infrastructure for parsing and composing. However, it seems that types are only implemented in the parsing component of [text], but not in the composing part. Yes, I could use the new [file] facility to edit Pd patches as binary files, but it seems the wrong tool, since Pd patch format is FUDI and [text] works with FUDI. 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] how to write different types to [text]
Anyone? Roman On Tue, 2022-03-22 at 22:33 +0100, Roman Haefeli wrote: > Hi > > [text get] has a second outlet for the type of the message. There is > a > distinction between messages terminated by semicolon and messages > terminated by comma. > > Is there also a way to add messages of different types? I haven't > found > any. [text set] and [text insert] usually add messages terminated by > semicolon (type 0). OK, there is [text fromlist], but I'm interested > in > a more granular way to edit the text buffer and add messages of > different types. > > 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
[PD] how to write different types to [text]
Hi [text get] has a second outlet for the type of the message. There is a distinction between messages terminated by semicolon and messages terminated by comma. Is there also a way to add messages of different types? I haven't found any. [text set] and [text insert] usually add messages terminated by semicolon (type 0). OK, there is [text fromlist], but I'm interested in a more granular way to edit the text buffer and add messages of different types. 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] Pd 0.52-1 - frozen dsp and gui in ubuntu 20.04
On Tue, 2022-03-22 at 16:00 +0100, Christof Ressi wrote: > > > I think the solution is simple: > > In jack_open_audio() replace > > if (advance_samples < DEFDACBLKSIZE) > advance_samples = DEFDACBLKSIZE; > with > > if (advance_samples < jack_blocksize) > advance_samples = jack_blocksize; > @Roman: can you give this a try? Yeah, it works. Now - without callbacks - it works with any setting for 'delay (ms)'. Of course, now the displayed settings doesn't always reflect the setting used internally. 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] Pd 0.52-1 - frozen dsp and gui in ubuntu 20.04
On Tue, 2022-03-22 at 15:23 +0100, IOhannes m zmoelnig wrote: > On 3/22/22 15:06, Roman Haefeli wrote: > > On Tue, 2022-03-22 at 14:56 +0100, Christof Ressi wrote: > > > > Anyway, I can open an issue to describe that in my case DSP > > > > only > > > > works with callbacks on. > > > Yes, please! The Jack backend is supposed to work regardless of > > > the > > > "callback" setting. > > > > But not regardless of the "delay (ms)" setting. If it is too low, > > Pd > > won't process audio. I don't know if there is a way to know > > beforehand > > what 'too low' is. It isn't necessarily a bug in Pd, I'd say. > > it's probably a bug in Pd if the DSP and the GUI both freeze. Indeed, if the buffer is set too small, then Pd GUI freezes! From my anecdotal testing, it looks like the critical value is predictable. As Christof said, the buffer cannot be smaller than JACK's blocksize. For instance with JACK @ 256 samples @ 44.1kHz (5.8ms): - Pd works with 6ms - Pd freezes with 5ms I guess the dialog could be designed in a way to set a lower boundary that is dependent on the detected JACK blocksize. I don't know, however, if Pd is able to detect the blocksize before DSP is turned on. 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] Pd 0.52-1 - frozen dsp and gui in ubuntu 20.04
On Tue, 2022-03-22 at 14:56 +0100, Christof Ressi wrote: > > Anyway, I can open an issue to describe that in my case DSP only > > works with callbacks on. > Yes, please! The Jack backend is supposed to work regardless of the > "callback" setting. But not regardless of the "delay (ms)" setting. If it is too low, Pd won't process audio. I don't know if there is a way to know beforehand what 'too low' is. It isn't necessarily a bug in Pd, I'd say. 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] Pd 0.52-1 - frozen dsp and gui in ubuntu 20.04
On Tue, 2022-03-22 at 10:45 -0300, Bruno Rohde wrote: > > Turn OFF (or ON) the "use callbacks" checkbox in the audio dialog. > > That did the trick, with callbacks ON DSP works. I never used it > before, and to be honest, I don't know what this does, but for now it > solved the problem. > Could you (or someone) explain briefly what this is for? Is there any > impact elsewhere (maybe performance) by using it enabled? From what I understand, using callbacks means that Pd processes audio as soon as it is provided by JACK. This means, Pd doesn't add additional latency as JACK client. But it also means, that when Pd isn't quick enought with writing back processed data, the whole JACK process with all clients experiences a drop-out. Without callbacks, Pd is less tightly coupled to JACK and uses a ringbuffer for input and output. The size of the ringbuffer is set in the 'delay(ms)' setting in the audio settings. From my experience, setting it too low causes Pd to not process audio at all. In my experience, this value is below 5ms, but this probably depends on JACK's blocksize setting. 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] M1 Externals
On Fri, 2022-03-18 at 18:04 -0400, me.grimm wrote: > hello, > > my old mac dead so had to get new M1 and starting from scratch. > > I see only a few externals so far compiled for the Darwin-amd64-32 I guess you mean Darwin-arm64-32. > > looking for the [comport] to give compiling a whirl i see v 0.2 from > 2012 here: https://puredata.info/downloads/comport > > that's the most recent repo? just checking in case im missing > something. There is: https://git.iem.at/pd/comport It has commits up to 2019. 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] Choices of IPC when using fast-forward
On Wed, 2022-03-16 at 16:00 -0500, Charles Z Henry wrote: > > other: is there a good way to start/stop processes other than > [ggee/shell]? cross-platform? There is [command] which works on Linux and macOS, but not on Windows. 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] phasor~ phase reset detection
On Wed, 2022-03-16 at 14:34 +, Jeppi Jeppi wrote: > Hi there, > I assume this has been discussed many times before but...what could > be simplest and most concise way to detect a phase reset of a phasor~ > with only plain vanilla objects? > I only need one bang when it goes back to 0. > It seems I should need snapshot~ and fexpr~ which is not that > elegant... Instead of detecting the phase reset of a real [phasor~] object, you could emulate a phasor~-like object with [vline~] and [metro~]. This would automatically give you bang with _precise_ timing. Compared to the [vline~] based phasor~, detecting a real phase reset of a [phasor~] has two drawbacks: * converting from signal to message adds 1 block latency * depending on how you generate the bangs, they are tied to block boundaries and thus not very precise and thus not suitable for a higher frequncy phasor. Nevertheless, I think it could be done with a handful of objects. Delay the [phasor~] signal by one sample and subtract the undelayed signal from it. The result is a signal that is usually slightly below zero and has one-sample-peaks close to 1 each time the phase resets. You then feed that to a block-sized table with [tabsend~]. On each block, you check the table with [array max] for the highest value. Actually, since the non-phase-reset samples should be below zero, anything above zero can be considered a phase-reset. Of course, you need to trigger [array max] every block with [bang~]. Filter out any values below zero and consider the index for all values above zero. The index tells you how much time passed since the last block boundary. You could convert the index value to ms and feed it to a [delay]. The result are bangs that correspond exactly with the phase resets. However, they are one block late, because you can only analyze a block of audio data _after_ it has been computed. I hope what I said makes sense and I did not make any mistakes. I haven't actually tested it yet. Ah, I should not forget to mention: [array max] detects only one peak. So this approach works only for phasor~ frequencies up to samplerate/blocksize (689 Hz @ 44.1k | 64 bs). 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] audio rate shift register abstraction with Pd vanilla
On Tue, 2022-02-22 at 17:08 -0500, Samuel Burt wrote: > >Is there some kind of delay introduced by [delwrite~] [delread~] > even when the delay is set to 0ms? Yes. 0 delay can only be achieved if the [delwrite~] is ordered before the [delread~] in the DSP graph. In your case, since you send your signal "upstream", the [delrwite~] is certain to be executed _after_ [delread~ ] and this adds a latency of one block (64 samples, if not re-blocked). 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] finding differences between almost identical patches
On Sun, 2022-02-20 at 13:03 +0100, ro...@dds.nl wrote: > hi list, > > is there a smart way to find the difference between 2 versions of a > patch? > Actually, the Pd file format is not really well "diff"able. Even if you edit only one object within canvas with many objects, the implicit order of the objects changes, which leads to all subsequent 'connect' statements to change. A really tiny edit can (and most often does) lead to a quite large diff. Also, this makes it hard to concurrently work on patches and merge changes. It will almost inevitably lead to merge conflicts. Still, I think a tool for tracking differences in text files like 'git diff' or Kdiff3 is your best bet. If I am looking at a diff for the purpose of figuring what has changed, I consider mainly the 'obj' statements and try to identify new or deleted objects while ignoring the 'connect' statements. Also, the 'canvas' statements seem to create a lot of noise when stuff has been moved around. Often, a change happened within a certain subpatch and looking at the diff gives you a clue about which subpatch is affected. To see and experience the actual difference, I open both version with Pd and compare visually and experimentally. 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] [Gem] bit depth of display
On Fri, 2022-02-18 at 09:47 +0100, cyrille henry wrote: > > Le 17/02/2022 à 21:24, Roman Haefeli a écrit : > > [...] > > > My impression is that the OpenGL side is all 32bit float. I tried > > 'quality 1' to [pix_texture] which does (from what I see) linear > > interpolation. And I also tried bicubic interpolation with a shader > > written by Cyrille Henry from 2007. The shader code is using type > > vec4 > > internally and GLSL spec says that this is 32bit float [1]. > > > > Computation is done with 32 bit float, but that does not mean that > the result is stored as a 32 bit float... > The GPGPU example shows how to keep precision in texture (but not to > render in high precision). > > In your example, you only need the gem windows to be rendered in > 10bits/color. Unfortunately, I don't thing there is flag or message > to allow this for now. You should create a feature request. > > As Claude says, adding dither is a good way to mask this problem. Yeah, thanks. Good to know that Gem window is rendered with 8bit. It turns out there is no real benefit in making sure the whole path is 10bit. It is very likely that the projector in the installation space supports only 8bit anyway. I was finally able to hack something together in your bicubic_interpolation.frag by generating some noise that I add to the result of the bicubic interpolation. It looks good to me. Thanks a lot for your inputs, Claude and Cyrille. 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] [Gem] bit depth of display
On Thu, 2022-02-17 at 19:30 +, Claude Heiland-Allen wrote: > > On 17/02/2022 17:59, Roman Haefeli wrote: > > the gradients between the > > pixels shows edges that look like low bit depth (and probably are > > due > > low bit depth). > No clue about high bit depth output. Possible workaround: a shader > that > does dithering could help mask the problem, Oh, good idea. I didn't think of that. > that is if the OpenGL > texture interpolation is not the source of the problem (hopefully > it's > done with floats, if not maybe you can do interpolation in the > shader > too after reading the texels without interpolation). Check the > OpenGL > specification for GL_LINEAR magnification filter details, maybe it > says > how much precision is guaranteed. My impression is that the OpenGL side is all 32bit float. I tried 'quality 1' to [pix_texture] which does (from what I see) linear interpolation. And I also tried bicubic interpolation with a shader written by Cyrille Henry from 2007. The shader code is using type vec4 internally and GLSL spec says that this is 32bit float [1]. Actually, since I'm already using a shader, I could try to add some noise there. Not totally sure how this should be done, though. > One thing you could do to diagnose is check pixel values of > neighbouring > bands to see if they are off by one (in which case suspect needing > higher bit depth output) or more (in which case suspect OpenGL > GL_LINEAR > precision being insufficient). Ok. I'll try to measure this. Thanks for your input, Roman [1] https://www.khronos.org/opengl/wiki/Data_Type_(GLSL) 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
[PD] [Gem] bit depth of display
Hi I have a Gem patch for an installation that basically maps a 1x12px image created with [pix_set] to a fullscreen [rectangle]. When the pixel values are close enough to each other, the gradients between the pixels shows edges that look like low bit depth (and probably are due low bit depth). I am looking for a way to display the Gem window with a higher bit depth. My external monitor advertises itself as capable of 30-bit (which I assume means 10 bit per channel). Here my questions: * Is it correct that in OpenGL calculations are done with floats? * Are the gradients calculated with high (>8bit) precision? * Is precision lost during transport to display? * What can be done to feed a monitor/projector with higher bit depth? * What can be done on macOS with a HDMI projector attached? Here a screenshot of the Gem display: https://netpd.org/~roman/tmp/12px-gradients.png 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] How to monitor a "dd" disk copy progress in Pd
On Tue, 2022-02-15 at 18:56 +0100, Ingo wrote:
>
> I'm trying to monitor the progress of a "dd" disk copy operaton in
> Pd. I'm on Debaian.
>
> When I send this to a console I can see the progress in the console
> (after the command):
> dd if=/dev/sdb of=/dev/sdc status=progress
>
> However, if I try to do the same thing within PD and send the same
> command to [shell] I get no output from s{shell].
The status output of dd is sent to stderr and [shell] only outputs the
stdout of the command.
> Is there anything I need to add to the command in order for shell to
> output the progress?
You could redirect stderr to stdout by appending ' 2>&1' to your shell
command.
Or you could use [command] from Deken that has a separate outlet for
stderr. Contrary to [shell], [command] is actively maintained, has more
features and more fine grained control over the commands it executes.
It is meant as a replacement for [shell], [popen], [system] and co that
are all not actively maintained anymore and lack features.
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] [midifile]
On Fri, 2022-02-11 at 00:03 +0100, IOhannes m zmölnig wrote: > On 2/10/22 23:12, Peter P. wrote: > > * IOhannes m zmoelnig [2022-02-10 13:36]: > > > i figure your argument is, that most of these have to learn Pd > > > from scratch > > > anyhow and will eventually come to the "use [trigger]" section in > > > the > > > documentation, > > > > Just out of curiosity, are you referring to > > 2.3.2. depth first message passing > > in http://msp.ucsd.edu/Pd_documentation/x2.htm#s3 > > ? > > no idea, i haven't read the documentation in a long time I-) 2.3.3 specifically covers fan-out connections. 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
