Re: [PD] How to monitor a "dd" disk copy progress in Pd

2022-02-15 Thread Roman Haefeli
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 > >

Re: [PD] [midifile]

2022-02-11 Thread Roman Haefeli
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]"

[PD] enforcing good practice (was: [midifile])

2022-02-10 Thread Roman Haefeli
On Thu, 2022-02-10 at 15:00 +0100, IOhannes m zmoelnig wrote: > > on a related note: > since Pd-0.52 it is no longer possible to connect a single outlet to > single inlet twice. > after reading this thread , i wonder whether this was premature and > whether we should undo that change. Can you

[PD] anti patterns (was: [midifile])

2022-02-10 Thread Roman Haefeli
On Thu, 2022-02-10 at 10:30 +0100, Roman Haefeli wrote: > 3) I'm personally not so fond of the idea of giving people patching > advice. Let me rewrite that to 'unsolicited patching advice'. I was the other day stumbling across a not-so-trivial-to-resolve bug. The problem turn

Re: [PD] [midifile]

2022-02-10 Thread Roman Haefeli
On Thu, 2022-02-10 at 10:09 +0100, Max wrote: > Should Pd warn the user when one outlet is connected to multiple > objects? I'd rather want Pd not to do that. 1) There are too many cases where fanning outlet connections are OK. 2) I believe it's more valuable if people do not fanning

Re: [PD] unauthorize / freeverb externals

2022-02-03 Thread Roman Haefeli
Hi Alex On Thu, 2022-02-03 at 17:15 +0100, alex tuca wrote: > > for a friend, i am looking for this precompiled windows64 externals. Hihi.. you make it sound a bit like "I'd like to buy some hemorrhoid ointment for a friend" ;-) > unauthorized > freeverb They are available in Deken¹, also

Re: [PD] [command] output

2022-02-03 Thread Roman Haefeli
On Thu, 2022-02-03 at 13:36 +0100, martin brinkmann wrote: > > sorry, i should have done this myself, but i was not entirely sure > whether this was a bug or i was doing something wrong... No need to be sorry. More important is that you actually discovered the bug. Roman signature.asc

Re: [PD] [command] output

2022-02-03 Thread Roman Haefeli
On Wed, 2022-02-02 at 12:06 +0100, IOhannes m zmoelnig wrote: > On 2/2/22 09:04, martin brinkmann wrote: > > > > i just like to confirm that the version available via deken will > indeed > output single number printout on the 1st outlet. > > https://github.com/pd-externals/command/issues/9

Re: [PD] [command] output

2022-02-02 Thread Roman Haefeli
On Wed, 2022-02-02 at 12:06 +0100, IOhannes m zmoelnig wrote: > On 2/2/22 09:04, martin brinkmann wrote: > > > > i just like to confirm that the version available via deken will > indeed > output single number printout on the 1st outlet. > > https://github.com/pd-externals/command/issues/9

[PD] [PD-announce] netpd v2.3.1

2022-02-01 Thread Roman Haefeli
Hey all A new release of netpd is out. Check here: https://github.com/reduzent/netpd/releases/tag/v2.3.1 For more info: https://www.netpd.org/About Get support here: https://untalk.netpd.org/ Some people are having jams at Thursday nights around 21:00 UTC (more beat oriented). Some other

Re: [PD] ggee shell does not work in 0.52

2022-02-01 Thread Roman Haefeli
On Tue, 2022-02-01 at 21:17 +0100, martin brinkmann wrote: > On 30/01/2022 21:43, Roman Haefeli wrote: > > > > If you want to preserve the exact output, use the binary format > > invoked > > with the -b flag [command -b]. This returns the results as list of >

Re: [PD] ggee shell does not work in 0.52

2022-01-30 Thread Roman Haefeli
On Sun, 2022-01-30 at 18:59 +0100, martin brinkmann wrote: > i have switched to > [command] and it works fine (except for numeric values being > converted > to floats and coming out of the left outlet (!?), but adding a (non > numeric) character to the output helped.) [command] parses stdout

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

2022-01-27 Thread Roman Haefeli
On Thu, 2022-01-27 at 20:59 +, Pierre Alexandre Tremblay wrote: > Sorry - they are all here: > > https://github.com/flucoma/flucoma-sc/releases/tag/nightly > You probably meant the Pd link, not SC: https://github.com/flucoma/flucoma-pd/releases/tag/nightly I'm sorry that I'm not much of

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

2022-01-27 Thread Roman Haefeli
On Thu, 2022-01-27 at 20:17 +, Pierre Alexandre Tremblay wrote: > the external works fine out of the help. Even more strange, > sometimes that works for a few minutes before getting these problems. Where can one get the external? Roman signature.asc Description: This is a digitally signed

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

2022-01-27 Thread Roman Haefeli
On Thu, 2022-01-27 at 17:45 +, Pierre Alexandre Tremblay wrote: > So I am fighting the fight of trying to unify the look of my > helpfiles across the 3 oses… and I think I got a bug but I cannot > trace where it is. The help-file loads fine in my Pd (0.52-1) on Ubuntu 20.04. However, I

Re: [PD] ggee shell does not work in 0.52

2022-01-26 Thread Roman Haefeli
Hi On Wed, 2022-01-26 at 10:21 +0100, martin brinkmann wrote: > or at least getting something from stdout does not work > anymore. (everything is fine in older versions > (0.51 and below). > > example: the shell help-patch "getting the date". > > it receives a bang from the right outlet, but

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

2022-01-24 Thread Roman Haefeli
On Sun, 2022-01-23 at 19:55 +0100, IOhannes m zmölnig wrote: > Am 23. Jänner 2022 18:42:18 MEZ schrieb Alexandre Torres Porres < > por...@gmail.com>: > > cool, thanks, can't we upload this to miller's site? > > > > Last time I checked, there was a total of 0 (zero) compiled externals > available

Re: [PD] A strange question (yet again)

2022-01-20 Thread Roman Haefeli
On Thu, 2022-01-20 at 16:46 +, Pierre Alexandre Tremblay wrote: > Sorry again for my obsessions with pd-vanilla which makes everything > harder - this one might be impossible! > > I’m trying to draw a spectrogram in pd-vanilla to match our waveform > visualisation options in FluCoMa for Max

Re: [PD] Trouble with updating number boxes, sliders, arrays on RPi - looking for a replacement to display an array

2022-01-15 Thread Roman Haefeli
On Sat, 2022-01-15 at 16:22 +0100, Ingo wrote: > Hi, > > I had some trouble with number boxes, sliders, etc. again. This time > on the Raspberry Pi. > > With the exact same programming they work fine on a i386 Intel > computer (Debian) but do not update graphically on the Rasperry Pi 4 > with

Re: [PD] Trouble with updating number boxes, sliders, arrays on RPi - looking for a replacement to display an array

2022-01-15 Thread Roman Haefeli
On Sat, 2022-01-15 at 16:22 +0100, Ingo wrote: > > > I had some trouble with number boxes, sliders, etc. again. This time > on the Raspberry Pi. > > With the exact same programming they work fine on a i386 Intel > computer (Debian) but do not update graphically on the Rasperry Pi 4 > with

Re: [PD] JACK and blocksize

2022-01-15 Thread Roman Haefeli
Hi Christof On Sat, 2022-01-15 at 15:51 +0100, Christof Ressi wrote: > > Oh, interesting. Haven't tried myself yet, but good to know that > > many > > patches wouldn't work. I can't get around using [receive~]. > > Have you seen my last reply ( >

Re: [PD] JACK and blocksize

2022-01-15 Thread Roman Haefeli
On Fri, 2022-01-14 at 23:17 +0100, Athos Bacchiocchi wrote: > I was curious so I compiled pd-0.52-1 on linux, with DEFDACBLKSIZE > set to 16. > I set Jack up with buffer size 16, and run pd with jack backend. > > Most of the patches in the help browser works, but at least these > objects fail to

Re: [PD] Store data in memory more efficiently than in arrays

2022-01-14 Thread Roman Haefeli
Hi IOhannes Interesting side-notes. Thanks! Roman On Fri, 2022-01-14 at 09:11 +0100, IOhannes m zmoelnig wrote: > > sidenote: of course we are not alone. > take for example the most popular programming language¹ of the last > few > years: > a boolean value ideally requires a single bit to be

Re: [PD] Store data in memory more efficiently than in arrays

2022-01-14 Thread Roman Haefeli
t_symbol *), which is 4 bytes on > > a > > 32-bit system and 8 bytes on a 64-bit systems. > > > > This means that even if you would add a "byte" type, the overall > > size of > > "t_word" would stay the same. > > > > Howeve

Re: [PD] JACK and blocksize

2022-01-12 Thread Roman Haefeli
Hi Thanks for your detailed explanations, Christof. On Wed, 2022-01-12 at 16:13 +0100, Christof Ressi wrote: > > Generally, there is no way to get lower I/O latency than 64 samples > in > Pd without changing DEFDACBLKSIZE and recompiling. I guess my question boils down to: Is it possible to

Re: [PD] JACK and blocksize

2022-01-12 Thread Roman Haefeli
On Wed, 2022-01-12 at 15:28 +0100, Peter P. wrote: > * Roman Haefeli [2022-01-12 15:08]: > > Hey all > > > > Using callbacks is certainly interesting for low-latency > > applications. > > I noticed that JACK allows blocksizes below 64, namely 32 and 16. &g

[PD] JACK and blocksize

2022-01-12 Thread Roman Haefeli
Hey all Using callbacks is certainly interesting for low-latency applications. I noticed that JACK allows blocksizes below 64, namely 32 and 16. However, those can only be used with callbacks disabled which means having to use an additional buffer again. I wonder if the blocksize of 64 is

[PD] Store data in memory more efficiently than in arrays

2022-01-12 Thread Roman Haefeli
Hi Sometimes I stored byte data (lists of bytes) in arrays. IIRC, I read once in IRC that one value in a Pd-array requires not 4 bytes, but 8 bytes on 64-bit systems. Since storing plain bytes seems not such an uncommon use case for me, I wonder if it can be done more efficiently. Not that I ever

Re: [PD] irreversibly high CPU usage with 'use callbacks' (macOS)

2022-01-12 Thread Roman Haefeli
Just another data point: I'm not able to reproduce this here: * macOS 10.15.7 * Pd 0.52-1-really * MacBook Pro 2016 Tested with CoreAudio and JACK Roman On Tue, 2022-01-11 at 23:43 +0100, Christof Ressi wrote: > Hi, > > I have noticed this myself just a few days ago (Pd

Re: [PD] Install path assumptions for [soundfiler] vs [file glob]

2022-01-11 Thread Roman Haefeli
On Tue, 2022-01-11 at 17:46 +0100, Christof Ressi wrote: > > I wondered if there was a way to get the path to a given object > > help, like in SuperCollider > > > > FluidBufAmpGate.class.filenameSymbol > Yes, that's possible with [file which] Yay, we finally have a way to programmatically check

Re: [PD] Install path assumptions for [soundfiler] vs [file glob]

2022-01-11 Thread Roman Haefeli
On Tue, 2022-01-11 at 13:41 +, Pierre Alexandre Tremblay wrote: > > With that footnote, I was hopeful to get [file which] to give me the > path of [media/] but no luck. [file which] only searches for files in all search paths. It doesn't work for directories. > > I’ve also tried to find a

Re: [PD] Install path assumptions for [soundfiler] vs [file glob]

2022-01-11 Thread Roman Haefeli
On Tue, 2022-01-11 at 11:31 +, Pierre Alexandre Tremblay wrote: > Dear all > > I am wondering if I my assumptions are wrong, or if there is a > discrepancy that needs solving (or not.) > > Setup: if one installs objects like our flucoma.org bundle, one might > have stuff included in the

Re: [PD] [file]: paths not relative to patch

2022-01-08 Thread Roman Haefeli
On Sat, 2022-01-08 at 19:11 +0100, Christof Ressi wrote: > Should we also provide a creation argument and float message for the > parent level? For example, [bang( -> [file patchdir 1] resp. [1( -> > [file patchdir] would output the parent patch directory, etc. This > would > make [pdcontrol]'s

Re: [PD] [file]: paths not relative to patch

2022-01-08 Thread Roman Haefeli
On Sat, 2022-01-08 at 10:42 +0100, Dan Wilcox wrote: > > If it were up to me, I would make [file] work like the other objects > and treat relative paths as relative to the canvas. I agree with Christof that this probably not a good idea after pd 0.52 has been released. > OTOH I know this

Re: [PD] [file]: paths not relative to patch

2022-01-08 Thread Roman Haefeli
On Sat, 2022-01-08 at 10:27 +0100, Dan Wilcox wrote: > I assume you already have a relative & absolute path check > implementation. Yes, but thanks anyway. > If not, I have a simple set of vanilla path abstractions, pre-[file]: > > p_absolute, p_makeabsolute, p_makerelative, etc >

Re: [PD] [file]: paths not relative to patch

2022-01-07 Thread Roman Haefeli
On Fri, 2022-01-07 at 23:41 +0100, Christof Ressi wrote: > > > > And what would you *do* want to use the current working > > > > directory? > > The patch's own directory, like all other file writing objects do. > Sorry, made a typo there. I meant: what would you do if you *do* want > to > use the

Re: [PD] [file]: paths not relative to patch

2022-01-07 Thread Roman Haefeli
On Fri, 2022-01-07 at 23:20 +0100, Christof Ressi wrote: > > > > And what would you *do* want to use the current working directory? The patch's own directory, like all other file writing objects do. > Generally, [file] doesn't do any magic. I don't consider starting from a sane working

Re: [PD] [file]: paths not relative to patch

2022-01-07 Thread Roman Haefeli
On Fri, 2022-01-07 at 22:58 +0100, Roman Haefeli wrote: > > Yeah, this works fine for finding already existing files, but as the > help-file says, you cannot resolve directories with. So, it cannot be > used for Sorry, I somehow hit 'send' in the middle of a sentence. I meant t

Re: [PD] [file]: paths not relative to patch

2022-01-07 Thread Roman Haefeli
On Fri, 2022-01-07 at 22:58 +0100, Roman Haefeli wrote: > > What I think should happen when instantiating any [file] objects is > to > set the working directory to the patch's directory and not to Pd's > start directory. I was wondering how objects before [file] did select a p

Re: [PD] [file]: paths not relative to patch

2022-01-07 Thread Roman Haefeli
On Fri, 2022-01-07 at 18:11 +0100, Antoine Rousseau wrote: > Have you tried [file which] ? Thanks for the hint. This helps for finding already existing files by their relative path, but it doesn't help for creating new files specified by relative path. Roman signature.asc Description: This is

Re: [PD] [file]: paths not relative to patch

2022-01-07 Thread Roman Haefeli
On Fri, 2022-01-07 at 19:57 +0100, Christof Ressi wrote: > > When using a relative path with the new [file], it is resolved > > relative > > to Pd's start location and not relative to the patch. > Actually, it's resolved to the current working directy. This is > expected behavior. Expected by

Re: [PD] [file]: paths not relative to patch

2022-01-07 Thread Roman Haefeli
On Fri, 2022-01-07 at 17:34 +0100, Roman Haefeli wrote: > Dear list > > When using a relative path with the new [file], it is resolved > relative > to Pd's start location and not relative to the patch. I'd like to work-around this with [dir(-[pdcontrol] which returns the directo

[PD] [file]: paths not relative to patch

2022-01-07 Thread Roman Haefeli
Dear list When using a relative path with the new [file], it is resolved relative to Pd's start location and not relative to the patch. This is unusual, as [text], [array], [table], [soundfile], etc. resolve relative paths relative to the patch. Also, I don't quite see the use case for relative

Re: [PD] Design / Philosophy principles behind Pd development

2022-01-04 Thread Roman Haefeli
On Tue, 2022-01-04 at 13:53 +0100, Jérôme Abel wrote: > The number of lines of code must be less than 10 000 ? Where did you get that from? $ cat pd/src/*.c | wc -l 84235 Roman signature.asc Description: This is a digitally signed message part ___

Re: [PD] Testing Pd builds with JACK

2021-12-16 Thread Roman Haefeli
On Thu, 2021-12-16 at 11:08 +0100, IOhannes m zmoelnig wrote: > > the jack2-osx-1.9.19.pkg installs a file that contains its contents: > > or just: > $ rm $(cat /usr/local/share/jack2/jack2-osx-files.txt) Oh, right. Thanks, that is certainly more thorough than what I did. And yes, the olde

Re: [PD] Testing Pd builds with JACK

2021-12-16 Thread Roman Haefeli
On Thu, 2021-12-16 at 11:28 +0100, IOhannes m zmoelnig wrote: > On 12/16/21 11:08, IOhannes m zmoelnig wrote: > > i don't know > > just to be sure: what i suggested is in no way canonical. > Ok. My question should be then: Do you take care of removing left-over files when switching JACK

Re: [PD] Testing Pd builds with JACK

2021-12-16 Thread Roman Haefeli
On Thu, 2021-12-16 at 10:05 +0100, Roman Haefeli wrote: > I usually wiped * all jack* binaries in /usr/local/bin * /usr/local/include/jack directory I forgot to mention /usr/local/lib/libjack* (those are probably the most crucial when it comes to Pd detecting JACK) Roman signature.

[PD] Testing Pd builds with JACK

2021-12-16 Thread Roman Haefeli
Hey all While testing the different Pd builds with different JACK versions, I wondered how JACK can be uninstalled cleanly. Both JACK versions I want to try come as a pkg, which installs a bunch of files to different places. From what I gather, there is no straight-forward way to remove

Re: [PD] JACK on macOS

2021-12-14 Thread Roman Haefeli
On Tue, 2021-12-14 at 16:04 +0100, Christof Ressi wrote: > Forgot to say: the callback scheduler will not be removed. If it > works > for you, by all means keep using it! Sorry for the alarmist tone, then. 'legacy' sounded to me like 'to be removed in the future'. Roman signature.asc

Re: [PD] JACK on macOS

2021-12-14 Thread Roman Haefeli
On Tue, 2021-12-14 at 15:53 +0100, Christof Ressi wrote: > > That said, I never really understood what 'callbacks' means. > It means that the Pd scheduler runs directly in the audio callback Thanks for your detailed explanation. It all makes sense now, especially why it is not advised to perform

Re: [PD] JACK on macOS

2021-12-14 Thread Roman Haefeli
On Tue, 2021-12-14 at 14:45 +0100, Christof Ressi wrote: > > 2. turn on "callbacks" in Pd's audio settings (it seems that this > > is > > required on macOS) > Are you sure? In my understanding, the "callback scheduler" is > generally > legacy and usually you would always use the "polling

Re: [PD] mc – multichannel extension for Pd

2021-12-08 Thread Roman Haefeli
On Wed, 2021-12-08 at 16:34 +0100, Roman Haefeli wrote: > I had only a close look at it I meant: I had only a quick glance at it [...] signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing l

Re: [PD] mc – multichannel extension for Pd

2021-12-08 Thread Roman Haefeli
Hey Thomas On Sun, 2021-12-05 at 17:22 +0100, Thomas Grill wrote: > > i'd like to make you aware of an abstraction library i have made > because of working more with multi-channel loudspeaker systems > lately. Quite a few times I thought it would practical to pack many audio cables into one. It

Re: [PD] Pd 0.52 test 2 is out

2021-11-23 Thread Roman Haefeli
On Tue, 2021-11-23 at 14:06 -0300, Alexandre Torres Porres wrote: > - the symbol box by default now is much wider, I always have to make > it shorter, who needs that big boxes most the time? can't we make the > same as before? I like it bigger. I usually make the number boxes bigger for them to

Re: [PD] Pd 0.52 test 2 is out

2021-11-23 Thread Roman Haefeli
On Tue, 2021-11-23 at 18:56 +0100, Christof Ressi wrote: > > I think *changing* existing shortcuts is a bad idea. So I think we > should leave the shortcuts as they were and use cmd+6 for the new > list atom. After all, a list atom is *not* a drop-in replacement for > a symbol atom (numbers and

Re: [PD] Hide backslash escapes in symbol atoms

2021-11-19 Thread Roman Haefeli
On Fri, 2021-11-19 at 11:51 +0100, IOhannes m zmoelnig wrote: > > Probably the best would be to have delimiters a display property of > the > list-box, rather than of the text itself. > as in the attached mockup. Sweet. +1! Roman signature.asc Description: This is a digitally signed message

Re: [PD] Hide backslash escapes in symbol atoms

2021-11-18 Thread Roman Haefeli
(now sending to list) On Thu, 2021-11-18 at 18:21 +0100, Antoine Rousseau wrote: > the discussion is there: > https://github.com/pure-data/pure-data/issues/824 Thanks for the link. > I've just closed this issue yesterday... I see, I didn't check for closed issues. > I personally didn't

Re: [PD] Hide backslash escapes in symbol atoms

2021-11-18 Thread Roman Haefeli
On Thu, 2021-11-18 at 12:26 -0300, Alexandre Torres Porres wrote: > I remember that discussion (I can try and find it) and I remember > people agreed symbol box should hide "\". > > I guess I can agree to that. In my idea, we know what's coming out of > a symbol box, it's a symbol, so if you have

[PD] Hide backslash escapes in symbol atoms

2021-11-18 Thread Roman Haefeli
Hi all It's just a cosmetic thing, nevertheless it concerns me. Up to 0.50, usage of whitespaces in symbol atoms was good. As in: Whitespaces could be used while typing into symbol atoms and the displayed value showed only the whitespaces without the backslashes for escaping them, while saving

Re: [PD] Fwd: random routing of 8 audio-streams to 8 outputs

2021-10-05 Thread Roman Haefeli
On Tue, 2021-10-05 at 00:08 +0200, Simon Iten wrote: > > > > is there a somewhat elegant way to route 8 audio outputs (from > readsf~) to 8 dac~ outputs randomly (on a bang for example)? You could use [mtx_*~ 8 8] from iemmatrix for the signal routing part. For feeding it, you could send '8'

[PD] [PD-announce] command external v0.1

2021-10-01 Thread Roman Haefeli
Hi The [command] external lets you execute commands from Pd. It is available on Deken for the following platforms: * Linux-amd64-32 * Linux-armv7-32 * Linux-i386-32 * Darwin-amd64-32 Not supported is Windows. More info here: https://github.com/pd-externals/command Roman

Re: [PD] external libraries for Raspberry Pi - how to compile?

2021-09-12 Thread Roman Haefeli
On Sun, 2021-09-12 at 21:30 +0200, IOhannes m zmölnig wrote: > On 9/12/21 21:03, Ingo wrote: > > Yes! I can confirm it definitely! > > That's why I ran into these problems in the first place. This is somewhat contradictory to: On Sun, 2021-09-12 at 11:36 +0200, Ingo wrote: > I just downloaded

Re: [PD] external libraries for Raspberry Pi - how to compile?

2021-09-12 Thread Roman Haefeli
On Sun, 2021-09-12 at 13:09 +0200, IOhannes m zmölnig wrote: > Am 12. September 2021 11:48:22 MESZ schrieb Roman Haefeli < > reduz...@gmail.com>: > > On Sun, 2021-09-12 at 11:36 +0200, Ingo wrote: > > > Yep, looks like [declare -path /usr/lib/puredata/extra/iem

Re: [PD] external libraries for Raspberry Pi - how to compile?

2021-09-12 Thread Roman Haefeli
On Sun, 2021-09-12 at 11:36 +0200, Ingo wrote: > Yep, looks like [declare -path /usr/lib/puredata/extra/iemlib -lib > iemlib] > should work but it doesn't. > I'm suspecting that certain objects are simply not compiled > correctly. I confirm iemlib 1.22 from Deken is broken for the Raspberry Pi OS

Re: [PD] external libraries for Raspberry Pi - how to compile?

2021-09-12 Thread Roman Haefeli
On Sun, 2021-09-12 at 09:29 +0200, Ingo wrote: > Declare is not the problem. > The .pd_linux files are missing in both the "apt-get pd-iemlib" > download as > well as in the Deken files of the RPi armv7. On a Raspberry Pi 4 with Raspberry Pi OS (ex. Raspbian): $ uname -a Linux heidelbeeri

Re: [PD] external libraries for Raspberry Pi - how to compile?

2021-09-12 Thread Roman Haefeli
On Sun, 2021-09-12 at 03:36 +0200, Ingo wrote: > > The very first errors I get are > > iemlib/splitfilename > couldn't create > > mergefilename > ... couldn't create Did you follow IOhannes' and Christof's advice: [declare -path iemlib -path iemabs -lib iemlib -lib iemlib1 -lib iemlib2] You

Re: [PD] executing commands from pd via pdreceive

2021-09-11 Thread Roman Haefeli
On Mon, 2021-09-06 at 21:51 +0200, Peter P. wrote: > > > Is there a way I can let pd know that the command > has finished executing? > For example by sending something back like > pdreceive udp | sh - ; echo "done" | pdsend 8889 localhost > udp > which sadly does not work? pdreceive

Re: [PD] New color format in patch source

2021-09-10 Thread Roman Haefeli
On Fri, 2021-09-10 at 17:13 +0200, IOhannes m zmoelnig wrote: > On 9/10/21 5:07 PM, Roman Haefeli wrote: > > Hey all > > > > I'm using current git master and found that the way color > > information > > of iemguis is stored in the patch file has changed. The

[PD] New color format in patch source

2021-09-10 Thread Roman Haefeli
Hey all I'm using current git master and found that the way color information of iemguis is stored in the patch file has changed. The number representing 6-bit-per-channel rgb values got replaced by a hexadecimal encoding like '#dfdfdf'. That is a huge advantage, but how far back are such patches

Re: [PD] Editing GOP abstractions

2021-09-10 Thread Roman Haefeli
On Fri, 2021-09-10 at 11:00 +0200, Roman Haefeli wrote: > On Fri, 2021-09-10 at 10:58 +0200, Roman Haefeli wrote: > > Ok, I could save > > with GOP disabled, edit it, enable GOP again. But that is still not > > a > > very good use experience. > > It's even

Re: [PD] Editing GOP abstractions

2021-09-10 Thread Roman Haefeli
On Fri, 2021-09-10 at 10:58 +0200, Roman Haefeli wrote: > Ok, I could save > with GOP disabled, edit it, enable GOP again. But that is still not a > very good use experience. It's even worse: When saving it, all (other) instances are reloaded and therefore loose their state. This is d

Re: [PD] Editing GOP abstractions

2021-09-10 Thread Roman Haefeli
On Fri, 2021-09-10 at 10:43 +0200, João Pais wrote: > basically you want to rewrite an object - doesn't matter if it's gop, > subpatch, or something else - without editing it yourself. No, I simply want to edit it manually in the patch editor, but cannot because the arguments are not visible.

[PD] Editing GOP abstractions

2021-09-10 Thread Roman Haefeli
Hi When using GOP abstractions with 'Hide object name and arguments' checked, I seem to not be able to change the arguments after creation. When rewriting the whole argument list in a new object is too tedious, I sometimes revert to editing the patch file with a text editor. Is there a way to

Re: [PD] [file]

2021-08-23 Thread Roman Haefeli
On Mon, 2021-08-23 at 11:10 +0200, Peter P. wrote: > * Roman Haefeli [2021-08-23 10:41]: > > One new object in Pd, one giant leap for Pd programmers! > Thanks Roman! > I can't seem to find this in 0.51.4 is it that new? > Much looking forward! It will be part of next 0.52 rele

[PD] [file]

2021-08-23 Thread Roman Haefeli
One new object in Pd, one giant leap for Pd programmers! What a great addition. Many thanks! Roman signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->

Re: [PD] JACK2 support on macOS

2021-07-30 Thread Roman Haefeli
On Fri, 2021-07-30 at 11:13 +0200, IOhannes m zmölnig wrote: On 7/30/21 10:23, Roman Haefeli wrote: > > > > > > Anyway, my impression is that someone installing JACK on macOS now > > is > > more likely to find JACK2 than JACK1. > > i don't think so. Ok.

Re: [PD] JACK2 support on macOS

2021-07-30 Thread Roman Haefeli
There is already an issue open with some more background information: https://github.com/pure-data/pure-data/issues/1190 Sorry for the noise. Roman On Fri, 2021-07-30 at 10:23 +0200, Roman Haefeli wrote: > Hey all > > On macOS, I used to download a package named JackOSX for installi

[PD] JACK2 support on macOS

2021-07-30 Thread Roman Haefeli
Hey all On macOS, I used to download a package named JackOSX for installing JACK (which seems to be the JACK1 implementation). Since a while now, the prominent source to get JACK seems https://jackaudio.org where you get JACK2 installers for macOS (and other platforms). Pd downloaded from

Re: [PD] JACK affects UDP rate

2021-07-28 Thread Roman Haefeli
On Wed, 2021-07-28 at 03:51 +0200, Christof Ressi wrote: > > On Linux, the receive buffer seems to be ~4kB, you as you already > > stated. > > Where did I state that? :-) From: https://lists.puredata.info/pipermail/pd-list/2021-07/129893.html "Back to TCP vs UDP: let's say you are sending

Re: [PD] JACK affects UDP rate

2021-07-27 Thread Roman Haefeli
23:59 +0200, Christof Ressi wrote: > On 23.07.2021 23:11, Roman Haefeli wrote: > > > > It would be nice, if more than > > one packet could be received per tick, of course, but then to > > buffer > > could simply be flushed, so that only "fresh" pack

Re: [PD] JACK affects UDP rate

2021-07-23 Thread Roman Haefeli
On Fri, 2021-07-23 at 21:52 +0200, Christof Ressi wrote: > When we overhauled the networking code, I noticed that the TCP and > UDP functions would both read up to N bytes (where N is currently > 4096) in a single recv() call. With TCP the buffer can contain > several FUDI (or other) messages, but

Re: [PD] JACK affects UDP rate

2021-07-23 Thread Roman Haefeli
On Fri, 2021-07-23 at 15:09 +0200, Christof Ressi wrote: > I assume you're using [iemnet] or [mrpeach] objects? Yes, [iemnet/udpclient]. But it seems the same applies to [netsend] (when receiving). > Those only read a single UDP packet in the poll function. OK, good to know. I'm glad I was not

[PD] JACK affects UDP rate

2021-07-23 Thread Roman Haefeli
Hi all, We experience "unexpected" latency with our software tpf-client [1] on macOS. When using JACK as audio-backend and using a blocksize [2] of 64, latency grows over time, growing whenever there are dropped packets. The issue appears only when all three criteria are met: * Pd is running

Re: [PD] sad news: RIP Martin Peach

2021-07-06 Thread Roman Haefeli
Thanks, Alexandre, for being brave and let us know about his passing away. I read about it yesterday on IRC. I never had the chance to meet him in person, but I had numerous pd- list conversations with him as most of the Pd projects I'm involved with use his externals, namely osc, binfile, net /

Re: [PD] Ability to access error messages from patch

2021-06-18 Thread Roman Haefeli
On Fri, 2021-06-18 at 13:57 +0200, IOhannes m zmölnig wrote: > i guess nobody actually has a need to query the selfsame object for > both > the visibility state of a window and to ask it where on the disk > supplementary files are located. +1 Roman signature.asc Description: This is a

Re: [PD] Ability to access error messages from patch

2021-06-14 Thread Roman Haefeli
On Mon, 2021-06-14 at 22:39 +0200, Roman Haefeli wrote: > > > [O] > | > [catch] > || > |[pd do_something_on_error_condition] > | > [read /tmp/foo.txt( After reading Christof's mail, I realize I got the order wrong. The other way around: 1) pass original mes

Re: [PD] Ability to access error messages from patch

2021-06-14 Thread Roman Haefeli
On Mon, 2021-06-14 at 09:10 -0700, Miller Puckette via Pd-list wrote: > Here's another idea: a "catch" object that passes messages from inlet > to outlet, but > then reports errors (somehow or other) only when those errors occur > while forwarding > the message. > I'm not sure I understand your

Re: [PD] Ability to access error messages from patch

2021-06-14 Thread Roman Haefeli
On Mon, 2021-06-14 at 17:01 +0200, Christof Ressi wrote: > > 1) is > > probably a more pragmatic approach that doesn't require any code to > > be > > changed and still covers all Pd objects _and_ externals that employ > > 'post'. > > I mean, it's probably fine for display purposes, but the help

Re: [PD] Ability to access error messages from patch

2021-06-14 Thread Roman Haefeli
On Mon, 2021-06-14 at 16:11 +0200, Christof Ressi wrote: > Ok, I think we have to seperate two things: > > 1) posting error messages > > 2) obtaining error codes > > I think Roman is primarly interested in 2), and 1), I guess... > so that his patches can programmatically deal with certain

Re: [PD] Ability to access error messages from patch

2021-06-14 Thread Roman Haefeli
On Mon, 2021-06-14 at 10:37 +0200, Peter P. wrote: > * Roman Haefeli [2021-06-14 10:24]: > [...] > > I am wondering about that, too. Maybe a [pderror] would be canvas- > > local > > and only report errors from objects belonging to the local canvas? > > And

Re: [PD] Ability to access error messages from patch

2021-06-14 Thread Roman Haefeli
On Mon, 2021-06-14 at 10:02 +0200, Peter P. wrote: > I am wondering how one would > parse these error messages if they came from one single object outlet > to > tell where the error originated from? I am wondering about that, too. Maybe a [pderror] would be canvas-local and only report errors

[PD] Ability to access error messages from patch

2021-06-13 Thread Roman Haefeli
Hi I was just discussing a feature request to an external (aoo) for posting error messages to the outlet instead of the Pd console. It reminded me that I often found error posts on the console limiting because they make the error condition inaccessible for the patch. Often there is no way to

Re: [PD] UDP server with Pd

2021-06-09 Thread Roman Haefeli
On Wed, 2021-06-09 at 10:41 -0400, Martin Peach wrote: > On Tue, Jun 8, 2021 at 12:08 PM Roman Haefeli > wrote: > > On Mon, 2021-06-07 at 23:51 +0200, Roman Haefeli wrote: > > > A quick follow-up. The new object [udpsrvr] works flawlessly. I > > couldn't find an

Re: [PD] UDP server with Pd

2021-06-08 Thread Roman Haefeli
On Mon, 2021-06-07 at 23:51 +0200, Roman Haefeli wrote: > On Mon, 2021-06-07 at 16:57 -0400, Martin Peach wrote: > > So I changed it to use sendto and it works a lot better. It > > receives > > from multiple clients while sending to any one. > > I added a [to ( mes

Re: [PD] UDP server with Pd

2021-06-07 Thread Roman Haefeli
On Mon, 2021-06-07 at 16:57 -0400, Martin Peach wrote: > So I changed it to use sendto and it works a lot better. It receives > from multiple clients while sending to any one. > I added a [to ( message to set the destination, and removed the > [connect( and [disconnect{ methods. > Thanks Christof

Re: [PD] UDP server with Pd

2021-06-07 Thread Roman Haefeli
On Sun, 2021-06-06 at 20:26 -0400, Martin Peach wrote: > > > If you have a [udpreceive 9898] as your 'server' it will receive from > anywhere on port 9898. So you can take the sender's ip and port from > the latest incoming message (route 'from' at the second outlet) and > use them to set the

Re: [PD] UDP server with Pd

2021-06-05 Thread Roman Haefeli
On Fri, 2021-06-04 at 19:09 -0400, Martin Peach wrote: > On Fri, Jun 4, 2021 at 6:16 PM Roman Haefeli > wrote: > > On Fri, 2021-06-04 at 23:27 +0200, Christof Ressi wrote: > > > Instead of waiting for > > > https://github.com/pure-data/pure-data/issues/949 > >

Re: [PD] UDP server with Pd

2021-06-04 Thread Roman Haefeli
On Fri, 2021-06-04 at 23:27 +0200, Christof Ressi wrote: > > > Instead of waiting for > https://github.com/pure-data/pure-data/issues/949 > - which will probably take months -, I am exploring stuff, partly out of curiousity. There is no expectation of anything to happen in certain time. >

Re: [PD] UDP server with Pd

2021-06-04 Thread Roman Haefeli
On Fri, 2021-06-04 at 23:03 +0200, Christof Ressi wrote: > > I guess I have to wait for > > https://github.com/pure-data/pure-data/issues/949 or learn C ;-) > I've mentioned [iemnet/udpserver] a couple of times now. Does it not > work for your use case? Yes, you did. Sorry for not reacting

Re: [PD] UDP server with Pd

2021-06-04 Thread Roman Haefeli
On Fri, 2021-06-04 at 21:34 +0200, Dan Wilcox wrote: > Ah yes, you are right. [timeout( is for TCP. I think I got that mixed > up with UDP previously closing itself after some sort of unknown host > return etc which we removed to make it "fire and forget." Ah, now I remember. It was that thread

<    1   2   3   4   5   6   7   8   9   10   >