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

[Christof Ressi]

It used to be XP, but since Pd 0.54 it's Vista because of the new WASAPI 
backend. The 32-bit version, however, still runs on XP because it is 
built without WASAPI.


On 14.05.2024 20:13, Alexandre Torres Porres wrote:
What is the minimal Windows OS version you can install Pd (the 64 bit 
one)? Every other option seems to mention the minimum OS, but this one 
is missing.


cheers

Em ter., 14 de mai. de 2024 às 11:26, Miller Puckette 
 escreveu:


To Pd-announce:

Pd version 0.55-0 test2 is available from
http://msp.ucsd.edu/software.htm
or (source only) via github: https://github.com/pure-data/pure-data

There was no "test1" - it never made it through the release
process.  Also,
for Mac users, the app will show up as "Pd-0.55-0test2c" but in fact
it's just test2.

cheers
Miller





___
Pd-announce mailing list
pd-annou...@lists.iem.at
https://lists.puredata.info/listinfo/pd-announce
___
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___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

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

[Christof Ressi]

I wonder what the updates to the audio interfacing and scheduler are?


See https://github.com/pure-data/pure-data/pull/1756.

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

Re: [PD] vcf~ producing output without input for 0Hz cutoff?

[Christof Ressi]

Alex made a great point there!

It's that very reason why DAW plugins usually don't let you go down all 
the way to zero. (Typically, they stop at 20 Hz or something.) If your 
signal has components below that, you'd need a high pass filter.


On 12.04.2024 09:35, Alexandre Torres Porres wrote:
oh sure, but that's more like a slew or glide and you don't go down to 
zero anyway :)


and if you're filtering audio, you don't want to keep inaudible stuff. 
All I'm saying is that if you are soing this to fade to slience you 
need a DC filter


Em sex., 12 de abr. de 2024 às 04:12, cyrille henry  
escreveu:


I don't think it's weird for a lowpass filter to go under 20Hz.
They are not restricted to audio signals.
I use them a lot to smooth control signals, or to replace line~.
(I really hate line~ to control sound amplitude or preset
transition, it's way too robotic)

cheers
c

Le 12/04/2024 à 08:01, Alexandre Torres Porres a écrit :
> and you got a strong DC component over there :)
>
> anyway, it also seems weird to have a lowpass or a bandpass
going as low as in the 20hz range. If you wanna do it just so it
fades out to silence, you need a DC filter, something like a [hip~
5] object, so when the lowpass, bandpass gets there, then you have
nothing.
>
> cheers
>
> Em qui., 11 de abr. de 2024 às 15:40, Antoine Rousseau
mailto:anto...@metalu.net>> escreveu:
>
>     Well, let's simplify a bit, forget all the filter complexity
(Q, slope, definition of the cutoff frequency...).
>
>     Let's just say that the output of a lowpass filter cannot
move faster than the cutoff frequency: a 1Hz filter output cannot
move faster than 1Hz (so it can't go back and forth in less than a
second or so), a 1kHz can't go back and forth in less than about
1ms, etc. The output of a 0Hz filter can't move... at all. When
you set the cutoff to 0Hz, the output freezes to its current
value. It won't magically decay to 0.
>
>     Hey, if you set the framerate of a movie to 0 frame/second,
it will just stop, and will show the same image forever; it won't
fade to black!
>
>     Antoine
>
>
>
>     Le jeu. 11 avr. 2024 à 14:08, Peter P.
mailto:peterpar...@fastmail.com>> a écrit :
>
>         * Antoine Rousseau mailto:anto...@metalu.net>> [2024-04-11 13:40]:
>          > That doesn't seem incorrect to me; after all, a
lowpass filter at 0Hz
>          > implies that its output is constant (any change would
involve frequencies >
>          > 0Hz).
>
>         Thanks Antoine,
>
>         Why does a lowpass filter, that has a cutoff frequency
of 0Hz imply that
>         it's output is constant?
>
>         I will describe the problem again hoping that I will
understand it
>         better myseld:
>         I have an oscillating input signal that has some DC
offset (unipolar
>         sawtooth from phasor~). I fade this signal's amplitude
to -inf dB using
>         [line~].
>
>         I also fade down the filter cutoff (defined as the -3dB
point of the
>         filter curve) from 400Hz to 0Hz. The filter will then
continue to produce an
>         non-decaying output.
>
>         If I fade down the filter cutoff down to only 1Hz, it's
output will decay (somehow
>         counterintuitively to me). This is the part I don't get.
>
>         I understand that vcf~ is a resonant filter, and it can
have a gain
>         greater 1 around the cutoff frequency, especially for
high Q values. The
>         above behavior can also be observed for Q=1.
>
>         Thanks for all hints!
>         Peter
>
>
>
>         ___
> 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

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


___
Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-management 

Re: [PD] vcf~ producing output without input for 0Hz cutoff?

[Christof Ressi]

Just expand on Antoine's post, let's look at the formula of Pd's 1-pole 
lowpass filter:


k = freq * 2pi / sr

y[i] = x[i] * k + y[i-1] * (1 - k)

For freq=0 this becomes:

y[i] = y[i-1]

As you can see, this would just repeat the previous output infinitely, 
ignoring the input altogether. There is no decay to zero!


The same reasoning applies to bandpass filters such as [vcf~].

Christof

On 12.04.2024 09:10, cyrille henry wrote:
I don't think it's weird for a lowpass filter to go under 20Hz. They 
are not restricted to audio signals.

I use them a lot to smooth control signals, or to replace line~.
(I really hate line~ to control sound amplitude or preset transition, 
it's way too robotic)


cheers
c

Le 12/04/2024 à 08:01, Alexandre Torres Porres a écrit :

and you got a strong DC component over there :)

anyway, it also seems weird to have a lowpass or a bandpass going as 
low as in the 20hz range. If you wanna do it just so it fades out to 
silence, you need a DC filter, something like a [hip~ 5] object, so 
when the lowpass, bandpass gets there, then you have nothing.


cheers

Em qui., 11 de abr. de 2024 às 15:40, Antoine Rousseau 
mailto:anto...@metalu.net>> escreveu:


    Well, let's simplify a bit, forget all the filter complexity (Q, 
slope, definition of the cutoff frequency...).


    Let's just say that the output of a lowpass filter cannot move 
faster than the cutoff frequency: a 1Hz filter output cannot move 
faster than 1Hz (so it can't go back and forth in less than a second 
or so), a 1kHz can't go back and forth in less than about 1ms, etc. 
The output of a 0Hz filter can't move... at all. When you set the 
cutoff to 0Hz, the output freezes to its current value. It won't 
magically decay to 0.


    Hey, if you set the framerate of a movie to 0 frame/second, it 
will just stop, and will show the same image forever; it won't fade 
to black!


    Antoine



    Le jeu. 11 avr. 2024 à 14:08, Peter P. > a écrit :


    * Antoine Rousseau > [2024-04-11 13:40]:
 > That doesn't seem incorrect to me; after all, a lowpass 
filter at 0Hz
 > implies that its output is constant (any change would 
involve frequencies >

 > 0Hz).

    Thanks Antoine,

    Why does a lowpass filter, that has a cutoff frequency of 0Hz 
imply that

    it's output is constant?

    I will describe the problem again hoping that I will 
understand it

    better myseld:
    I have an oscillating input signal that has some DC offset 
(unipolar
    sawtooth from phasor~). I fade this signal's amplitude to 
-inf dB using

    [line~].

    I also fade down the filter cutoff (defined as the -3dB point 
of the
    filter curve) from 400Hz to 0Hz. The filter will then 
continue to produce an

    non-decaying output.

    If I fade down the filter cutoff down to only 1Hz, it's 
output will decay (somehow

    counterintuitively to me). This is the part I don't get.

    I understand that vcf~ is a resonant filter, and it can have 
a gain
    greater 1 around the cutoff frequency, especially for high Q 
values. The

    above behavior can also be observed for Q=1.

    Thanks for all hints!
    Peter



    ___
    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 




___
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




___
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

[Christof Ressi]

The default list method distributes the elements over all inlets. 
However, some objects define a custom list method! See [list], [array 
set], [send], etc.


Christof

On 14.03.2024 17:36, Peter P. wrote:

* Roman Haefeli  [2024-03-14 15:57]:

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 \

Thanks Roman!
I knew about this with the simple math objects, but can someone confirm
that it does work for all objects?

Best, P



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




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

Re: [PD] RIP Ed Kelly

[Christof Ressi]

What a tragedy. My deep condolences to his friends and family. I haven't 
really known Ed, just heard stories about him, but it is great to see 
that Dan, you and others care so much for him and try to preserve his work!


On 10.03.2024 18:49, Alexandre Torres Porres wrote:
Tehomas Bow on facebook gave us the bad news. He had a stroke and 
fell, got injured and passed away this friday. He leaves us soon, just 
before turning 50. Ed was quite a fun character, I loved him, he'll be 
missed. Rest in Peace.


* March 29th, 1974
† March 8th, 2024

___
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] help making sense of [readsf~]

[Christof Ressi]

On 07.03.2024 04:43, Alexandre Torres Porres wrote:



Em qui., 7 de mar. de 2024 às 00:27, Christof Ressi 
 escreveu:


(BTW, the equivalent SuperCollider object would be DiskIn UGen +
Buffer.cueSoundFile; there you don't even have the chance to skip
the buffering step.)


This is a much better design. I don't mind the latency, but I'd really 
like to tell the object to just play and it can then work out when it 
is ready and start doing it :)
Keep in mind that this is not deterministic, i.e. playback will just 
start whenever the data is ready. This is probably fine for many uses 
cases, but if you want sample accurate playback, you'd need to wait 
until Buffer.cueSoundFile has completed before creating the DiskIn, 
similar to [readsf~].


In fact, I would like to suggest a new "play" message, that would do 
exactly this: "open" + "start', making sure there are no dropouts...


Actually, I had already thought about that! There could be an option 
that makes [readsf~] non-blocking, i.e. the perform routine does not 
wait on a condition variable if the buffer is empty, instead it would 
just output silence. This would be essentially the same behavior as 
DiskIn. I thought of doing this with a flag to the "open" message: [open 
-n , start(


But I agree that [play ( looks much nicer and less obscure.

I just opened a feature request: 
https://github.com/pure-data/pure-data/issues/2205 :)




Seems like a job to you by the way ;)___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] help making sense of [readsf~]

[Christof Ressi]

On 07.03.2024 04:05, Alexandre Torres Porres wrote:

thing is I can never hear dropouts, don't think I've ever had 
problems, then it seemed that the issue might be first accessing an 
uncached file, which kinda made sense why I never faced this I 
also have an abstraction that is a wrap around readsf~ that doesn't 
care about this and I use it many times to randomly play samples from 
sample banks, never found anything funny (ok, my performances are 
usually loud and noisy anyway, haha)
I definitely did get dropouts. Maybe you just never noticed it :-D Or 
macOS has just faster file I/O than Windows (which I believe is indeed 
the case).


And for testing now, I just recorded a new file (ok it was in Pd), 
then renamed it and moved it elsewhere, no dropouts either, did my 
system cash this somehow and kept track of it?

Yes, very likely.


Anyway, I really like how Dan put it... which is you "may" get 
dropouts... "if you do" then you should do this... because putting 
this as something thas *has* to be done everytime doesn't seem 
right...  :)


I don't agree. The problem with "if you do" is that it isn't portable. 
If you don't care about writing portable patches, that's probably fine, 
but I think we should really teach users the correct and portable way. 
The very idea of [readsf~] is that you don't open the file on the audio 
thread, but when you do [open , start( you indirectly block the audio 
thread. Just don't do it!


I've already mentioned this, but if you do [open , start( it can 
become quite awkward to change later. Better do the right thing from the 
beginning.


(BTW, the equivalent SuperCollider object would be DiskIn UGen + 
Buffer.cueSoundFile; there you don't even have the chance to skip the 
buffering step.)


Christof





Em qua., 6 de mar. de 2024 às 23:33, Christof Ressi 
 escreveu:


On 07.03.2024 02:38, Alexandre Torres Porres wrote:

> on first accessing a file

I think this would cause more confusion than it would help. (What
does
"first accessing" actually mean?)

I wrote about the case where the file is not yet cached by the OS,
but
IMO that is too specific for a help patch. Also, it isn't the *only*
case that can cause a dropout. In general, file I/O is
non-deterministic
and you are at the mercy of your OS.

I think it's enough to tell users that the buffer needs to be
filled in
time.

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

Re: [PD] help making sense of [readsf~]

[Christof Ressi]

On 07.03.2024 02:38, Alexandre Torres Porres wrote:


on first accessing a file


I think this would cause more confusion than it would help. (What does 
"first accessing" actually mean?)


I wrote about the case where the file is not yet cached by the OS, but 
IMO that is too specific for a help patch. Also, it isn't the *only* 
case that can cause a dropout. In general, file I/O is non-deterministic 
and you are at the mercy of your OS.


I think it's enough to tell users that the buffer needs to be filled in 
time.


Christof




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

[PD] help making sense of [readsf~]

[Christof Ressi]

On 07.03.2024 01:33, Alexandre Torres Porres wrote:

Em qua., 6 de mar. de 2024 às 21:27, Alexandre Torres Porres 
 escreveu:


I got this rather old 2013 macbook air, and using it with a delay
of only 5ms doesn't give me any noticeable dropout!

As I said, you likely don't notice it if the file is (still) cached by 
the OS. You need to test with files that aren't cached! On Windows you 
can manually clear the file cache (https://stackoverflow.com/a/9649439), 
but I don't know about macOS.


btw, 4ms chokes and causes dropouts when testing audio with the 
audio-mid test patch, just playing a sine wave...


That's a problem with the scheduler. With my scheduler fixes, you should 
be able to go lower: https://github.com/pure-data/pure-data/pull/1756


But again, you should really test with uncached files and/or with a 
fairly high CPU load.


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

Re: [PD] help making sense of [readsf~]

[Christof Ressi]

On 07.03.2024 01:27, Alexandre Torres Porres wrote:
Em seg., 4 de mar. de 2024 às 02:25, Christof Ressi 
 escreveu:


A worker thread is reading data from the given file and fills a
buffer.


and this buffer size is set via the 2nd argument, right?

Yes!


If the buffer is full, it waits until there is space. The thread
starts
to do its job right after the [open( message.


And it'll have space when it starts playing, which frees the data from 
the buffer, huh?
Yes, although "frees the data" is the wrong term. The perform routine 
reads a range of samples and advances the read pointer, after which 
these samples can be *overwritten* by the worker thread. It's just a 
simple ringbuffer.


Once we send the [start( message, the perform method simply tries to
read a block of samples from the buffer and copy it to the outlets. If
there is not enough data in the buffer, the method blocks - which is
something we definitely want to avoid! This is exactly the reason
why we
need to wait a little bit between the [open( message and the [start(
message; otherwise the perform routine might have to wait for the
buffer, causing a dropout.


But it's not like we need for the whole buffer to get filled before 
playing, right? So we can read and free from the buffer while it's 
being filled.
Yes! Although in practice the buffer will be filled pretty quickly once 
the soundfile has been opened. One could say that the perform routine 
"drives" the worker thread.


The second argument for [readsf~] is the size of the buffer. The
default
value seems to be 262144 bytes (per channel). In single-precision Pd
that corresponds to 65536 samples, which should be more than enough. I
think this value comes from the times where everybody had slow
HDDs with
unpredictable seek times; for modern SSDs it can be much smaller,
but we
probably don't care about a few kilobytes.


I see.

(BTW, I have no idea why the help patch uses a buffer size of 1 MB...)


seems weird in fact to require anything bigger than this, really, and 
this should be clear in the help file! When should one care and feel 
like 65536 isn't enough?

Pretty much never.


[writesf~] behaves just the otherway round. Since the perform
routine is
the producer, we don't need to wait after the [open( message. But
after
we send [stop(, we should to wait for the worker thread to drain the
buffer and write the data to disk before we send another [open(
message.


maybe worth mentioning.

Actually, I forgot something important:

Of course, the worker thread must also *open* the file! If the
file is not yet cached by the OS, this can indeed take a few
milliseconds.If you don't add some delay between "open" and
"start", you might notice that you get a dropout the very first
time, but not on subsequent times.

In fact, if you don't wait between "open" and "start", the perform
method almost certainly blocks. However, often we don't notice
because it may be "absorbed" by Pd's own ringbuffer (= "Delay" in
the audio settings).


Thing is, I don't think I've ever noticed a dropout and have been 
ignoring this warning and playing files right away forever, since I 
started using Pd in the 2000s... I got this rather old 2013 macbook 
air, and using it with a delay of only 5ms doesn't give me any 
noticeable dropout!
I did and still do notice it! Opening a file (that is not cached by the 
OS) can take a few milliseconds. If your delay setting is low and CPU 
load is high, you can easily get a dropout.


Can others test this?

This is why I was assuming that it was a concern for pretty old 
computers. I thought maybe it was a cpu issue, but I see it could also 
be hard drive related now. This ver old macbook air has got SSDs anyway...


Anyway, I agree that the help needs some more clarification! (Just
make sure you really understand how the object works before
changing the help patch :)

that's what I am doing :)

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

Re: [PD] help making sense of [readsf~]

[Christof Ressi]

not necessarily as a "always delay before playing" sort of thing but 
more a short description of how it works,
I agree! It's always better when the user actually understands *why* 
they need to do something.


In general, though, I would advice everyone to consider a delay between 
"open" and "start" when you design your patches, in particular if you 
plan to distribute it to other people.


[open , start( is convenient, but it can be hard to refactor at a 
later stage!


Personally, when I build a playlist in Pd, I have one or more [readsf~] 
objects and cycle between them. For example:


| cue  | readsf~ 1 | readsf~ 2 |
|  | - | - |
| 1| play 1| open 2|
| 2| open 3| play 2|
| 3| play 3| open 4|
| 4| open 5| play 4|
| 5| play 5| open 6|

etc.

I think you get the pattern.

Christof

On 04.03.2024 13:07, Dan Wilcox wrote:
*This* is a good point and worth noting, not necessarily as a "always 
delay before playing" sort of thing but more a short description of 
how it works, then a note like "if you experience occasional dropouts 
on first accessing a file, consider adding a small delay after opening 
but *before* playing."



On Mar 4, 2024, at 1:01 PM, pd-list-requ...@lists.iem.at wrote:

Message: 1
Date: Mon, 4 Mar 2024 12:55:54 +0100
From: Christof Ressi 
To:pd-list@lists.iem.at
Subject: Re: [PD] help making sense of [readsf~]
Message-ID: <2176516f-edbe-4982-bcfa-b7002952a...@christofressi.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Actually, I forgot something important:

Of course, the worker thread must also *open* the file! If the file is
not yet cached by the OS, this can indeed take a few milliseconds.If you
don't add some delay between "open" and "start", you might notice that
you get a dropout the very first time, but not on subsequent times.

In fact, if you don't wait between "open" and "start", the perform
method almost certainly blocks. However, often we don't notice because
it may be "absorbed" by Pd's own ringbuffer (= "Delay" in the audio
settings).

Anyway, I agree that the help needs some more clarification! (Just make
sure you really understand how the object works before changing the help
patch :)

?Christof



Dan Wilcox
danomatika.com <http://danomatika.com>
robotcowboy.com <http://robotcowboy.com>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] help making sense of [readsf~]

[Christof Ressi]

As Christof says, fine tuning the reader buffer size could be thought 
of as fine tuning the audio buffer length, ie. a 64 block size is 
faster but has less space/time if your patch does some really CPU 
intensive stuff. If you don't need super responsively, you can 
increase the block size.


Just to clarify: the buffer for readsf~ itself does not cause any delay, 
so larger values don't hurt (except for wasting some kilobytes). The 
latency is explicitly controlled by the user as the time between the 
"open" and "start" message.


(The reason why the buffer itself does not cause a delay is because the 
worker thread is "eager", i.e. it already has all the data available and 
so it always fills the buffer as fast as possible. This is different to 
an audio device where the audio input is produced at the same rate as it 
is consumed.)


I have never personally needed to use anything but the default readsf~ 
buffer size.
Yes, as I noted, the default buffer size is 65356 samples, which is over 
1 second of audio at 48 kHz. This is much more than we will ever need on 
modern systems. The user only needs to think about the wait time between 
"open" and "start" to avoid *initial* dropouts.


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

Re: [PD] help making sense of [readsf~]

[Christof Ressi]

Actually, I forgot something important:

Of course, the worker thread must also *open* the file! If the file is 
not yet cached by the OS, this can indeed take a few milliseconds.If you 
don't add some delay between "open" and "start", you might notice that 
you get a dropout the very first time, but not on subsequent times.


In fact, if you don't wait between "open" and "start", the perform 
method almost certainly blocks. However, often we don't notice because 
it may be "absorbed" by Pd's own ringbuffer (= "Delay" in the audio 
settings).


Anyway, I agree that the help needs some more clarification! (Just make 
sure you really understand how the object works before changing the help 
patch :)


 Christof

On 04.03.2024 06:23, Christof Ressi wrote:

Hi,

making it seem it would load the file into an internal memory and not 
just read directly from the disk

The help file says "soundfile playback from disk"...

Here's how the object works:

A worker thread is reading data from the given file and fills a 
buffer. If the buffer is full, it waits until there is space. The 
thread starts to do its job right after the [open( message.


Once we send the [start( message, the perform method simply tries to 
read a block of samples from the buffer and copy it to the outlets. If 
there is not enough data in the buffer, the method blocks - which is 
something we definitely want to avoid! This is exactly the reason why 
we need to wait a little bit between the [open( message and the 
[start( message; otherwise the perform routine might have to wait for 
the buffer, causing a dropout.


The second argument for [readsf~] is the size of the buffer. The 
default value seems to be 262144 bytes (per channel). In 
single-precision Pd that corresponds to 65536 samples, which should be 
more than enough. I think this value comes from the times where 
everybody had slow HDDs with unpredictable seek times; for modern SSDs 
it can be much smaller, but we probably don't care about a few kilobytes.


(BTW, I have no idea why the help patch uses a buffer size of 1 MB...)

---

[writesf~] behaves just the otherway round. Since the perform routine 
is the producer, we don't need to wait after the [open( message. But 
after we send [stop(, we should to wait for the worker thread to drain 
the buffer and write the data to disk before we send another [open( 
message.


Christof

On 04.03.2024 05:24, Alexandre Torres Porres wrote:
Hi, a discussion on facebook led me to revise the help file of 
[readsf~] and I'm making some edits and changes. It seems it wasn't 
all to clear how it works, making it seem it would load the file into 
an internal memory and not just read directly from the disk, and in 
fact I'm not really sure how it works.


Also, the help has been saying forever how one should open a file "a 
bit" in advance, which is vague and it also doesn't make it clear why 
and how long soon... it also says it starts reading from the file 
right away, but doesn't play it until you say so... this is what 
makes it a bit confusing to people I guess, cause it seems to load 
into memory. Now, I believe there is some operation that is done in 
advance and then it adds some latency maybe, so if you do it in 
advance you get to manage this a bit better, is that it?


Can we have and add a bit more information about it?

Also, is it the case that this used to be a somewhat significant 
issue back in the day, which means this has become not significant 
all for a while?


Last, but not least, I can't make much sense of the 2nd argument. I 
had a look at the code to see what is the default value (which is 
also the minimum allowed value), something I always put on the help 
files, and I wonder if this is some kind of memory buffer that we 
load the file into... Moreover, why would someone need a bigger 
buffer than the default value?


I need this information well sorted to make this help file as nice as 
the others.


Cheers!

___
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___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] help making sense of [readsf~]

[Christof Ressi]

Hi,

making it seem it would load the file into an internal memory and not 
just read directly from the disk

The help file says "soundfile playback from disk"...

Here's how the object works:

A worker thread is reading data from the given file and fills a buffer. 
If the buffer is full, it waits until there is space. The thread starts 
to do its job right after the [open( message.


Once we send the [start( message, the perform method simply tries to 
read a block of samples from the buffer and copy it to the outlets. If 
there is not enough data in the buffer, the method blocks - which is 
something we definitely want to avoid! This is exactly the reason why we 
need to wait a little bit between the [open( message and the [start( 
message; otherwise the perform routine might have to wait for the 
buffer, causing a dropout.


The second argument for [readsf~] is the size of the buffer. The default 
value seems to be 262144 bytes (per channel). In single-precision Pd 
that corresponds to 65536 samples, which should be more than enough. I 
think this value comes from the times where everybody had slow HDDs with 
unpredictable seek times; for modern SSDs it can be much smaller, but we 
probably don't care about a few kilobytes.


(BTW, I have no idea why the help patch uses a buffer size of 1 MB...)

---

[writesf~] behaves just the otherway round. Since the perform routine is 
the producer, we don't need to wait after the [open( message. But after 
we send [stop(, we should to wait for the worker thread to drain the 
buffer and write the data to disk before we send another [open( message.


Christof

On 04.03.2024 05:24, Alexandre Torres Porres wrote:
Hi, a discussion on facebook led me to revise the help file of 
[readsf~] and I'm making some edits and changes. It seems it wasn't 
all to clear how it works, making it seem it would load the file into 
an internal memory and not just read directly from the disk, and in 
fact I'm not really sure how it works.


Also, the help has been saying forever how one should open a file "a 
bit" in advance, which is vague and it also doesn't make it clear why 
and how long soon... it also says it starts reading from the file 
right away, but doesn't play it until you say so... this is what makes 
it a bit confusing to people I guess, cause it seems to load into 
memory. Now, I believe there is some operation that is done in advance 
and then it adds some latency maybe, so if you do it in advance you 
get to manage this a bit better, is that it?


Can we have and add a bit more information about it?

Also, is it the case that this used to be a somewhat significant issue 
back in the day, which means this has become not significant all for a 
while?


Last, but not least, I can't make much sense of the 2nd argument. I 
had a look at the code to see what is the default value (which is also 
the minimum allowed value), something I always put on the help files, 
and I wonder if this is some kind of memory buffer that we load the 
file into... Moreover, why would someone need a bigger buffer than the 
default value?


I need this information well sorted to make this help file as nice as 
the others.


Cheers!

___
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] [vstplugin~] v0.6.0 final release!

[Christof Ressi]

(taken it back to the list)


Do you have a suggestion for ambisonic plugins?

Here are some free and open source ambisonic plugins:

IEM plugins: https://plugins.iem.at/

SPARTA: https://leomccormack.github.io/sparta-site/

ICST plugins: https://ambisonics.ch/page/icst-ambisonics-plugins

Personally, I use the IEM plugins. One very nice thing about those is 
that they can automatically deduce the ambisonics order from the channel 
count. For example, let's take the following stereo encoder:


[vstplugin~ -e -m StereoEncoder 2 16]

Here I create it with 16 output channels, so the StereoEncoder will 
automatically output a 3rd order ambisonic signals


If I send the [channels 24( message to [vstplugin~] it will switch to 24 
output channels and the StereoEncoder will automatically switch to 4th 
order.


If you want to change the ambisonics order of your whole patch, you just 
need to send the same [channels ( message to all your [vstplugin~] 
instances and the [send~]/[receive~]/[catch~] objects that make up your 
"ambisonic busses". (You don't have to do this for [throw~].)


Christof

On 02.03.2024 09:51, Edwin van der Heide wrote:

Dear Christof,

Very nice!

Do you have a suggestion for ambisonic plugins?

Best!

Edwin

On 1 Mar 2024, at 23:24, Christof Ressi  wrote:



Hi,

I have just released [vstplugin~] v0.6.0! Binaries are already 
available on Deken (search for "vstplugin~").


The most important new feature is /support for multichannel signals/: 
a single input or output signal can now contain multiple channels. 
This is particularly handy for spatialization plugins with many 
channels, such as higher-order ambisonics. Not only does it save you 
from drawing lots of patch cords, it also allows you to change the 
channel count dynamically! For example, you can now freely change the 
ambisonics order without rewriting your patch.


IMPORTANT: previous versions would hide certain (non-automatable) 
parameters in VST3 plugins. This has been fixed, but as a consequence, 
parameter might have changed. [vstplugin~] prints a warning for every 
plugin that is affected by this change!


Here is the full changelog: 
https://git.iem.at/pd/vstplugin/-/releases/v0.6.0


Please test and report any issues at Issues · Pure Data libraries / 
vstplugin · GitLab <https://git.iem.at/pd/vstplugin/-/issues>.


Have fun!

Christof

___
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

[PD] [vstplugin~] v0.6.0 final release!

[Christof Ressi]

Hi,

I have just released [vstplugin~] v0.6.0! Binaries are already available 
on Deken (search for "vstplugin~").


The most important new feature is /support for multichannel signals/: a 
single input or output signal can now contain multiple channels. This is 
particularly handy for spatialization plugins with many channels, such 
as higher-order ambisonics. Not only does it save you from drawing lots 
of patch cords, it also allows you to change the channel count 
dynamically! For example, you can now freely change the ambisonics order 
without rewriting your patch.


IMPORTANT: previous versions would hide certain (non-automatable) 
parameters in VST3 plugins. This has been fixed, but as a consequence, 
parameter might have changed. [vstplugin~] prints a warning for every 
plugin that is affected by this change!


Here is the full changelog: 
https://git.iem.at/pd/vstplugin/-/releases/v0.6.0


Please test and report any issues at Issues · Pure Data libraries / 
vstplugin · GitLab .


Have fun!

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

Re: [PD] [vstplugin~] v0.6-test1

[Christof Ressi]

Thanks for confirming!

On 19.02.2024 16:41, baptiste chatel wrote:

Thanks, it works fine !

Le mar. 13 févr. 2024 à 23:14, Christof Ressi  
a écrit :


Thanks to IOhannes, I have just replaced the Linux amd64 binary on
Deken with one that is built against glibc 2.31 (I believe).
Please give it a try and report back!

On 13.02.2024 18:33, baptiste chatel wrote:

Sadly, it is built on glibc 2.36 and my mint only has 2.35, same
with the latest ubuntu LTS... What is your target distro ?

Le lun. 5 févr. 2024 à 13:44, Christof Ressi
 a écrit :

Of course, [vstplugin~] is also available on Deken!

On 05.02.2024 13:41, Christof Ressi wrote:


Hi,

here is a first test release of [vstplugin~] v0.6:
https://git.iem.at/pd/vstplugin/-/releases/v0.6-test1

NOTE: previous versions would hide certain (non-automatable)
parameters in VST3 plugins. This has been fixed, but as a
consequence parameter indexes might have changed.
[vstplugin~] prints a warning for every plugin that is
affected by this change!

Please test and report any issues at Issues · Pure Data
libraries / vstplugin · GitLab
<https://git.iem.at/pd/vstplugin/-/issues>.

Have fun!

Christof


___
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
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [vstplugin~] v0.6-test1

[Christof Ressi]

Thanks to IOhannes, I have just replaced the Linux amd64 binary on Deken 
with one that is built against glibc 2.31 (I believe). Please give it a 
try and report back!


On 13.02.2024 18:33, baptiste chatel wrote:
Sadly, it is built on glibc 2.36 and my mint only has 2.35, same with 
the latest ubuntu LTS... What is your target distro ?


Le lun. 5 févr. 2024 à 13:44, Christof Ressi  
a écrit :


Of course, [vstplugin~] is also available on Deken!

On 05.02.2024 13:41, Christof Ressi wrote:


Hi,

here is a first test release of [vstplugin~] v0.6:
https://git.iem.at/pd/vstplugin/-/releases/v0.6-test1

NOTE: previous versions would hide certain (non-automatable)
parameters in VST3 plugins. This has been fixed, but as a
consequence parameter indexes might have changed. [vstplugin~]
prints a warning for every plugin that is affected by this change!

Please test and report any issues at Issues · Pure Data libraries
/ vstplugin · GitLab <https://git.iem.at/pd/vstplugin/-/issues>.

Have fun!

Christof


___
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
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [vstplugin~] v0.6-test1

[Christof Ressi]

However, for whatever reasons, Christof changed the base for the amd64 builds 
to the 'gcc' Docker image which is based on Debian/bookworm, so this is most 
likely your baseline glibc.
Look who's the author ;-) 
https://git.iem.at/pd/vstplugin/-/commit/49bcf453314469bfad2483d2766229f04df1df8f


Which image should I use instead?




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

Re: [PD] [vstplugin~] v0.6-test1

[Christof Ressi]

I forgot to mention an important new feature: /[vstplugin~] can now deal 
with multichannel signals!/


This is particularly handy for spatialization plugins with many 
channels. One signal may now contain a full 64-channel ambisonics bus. 
With the IEM plugins (https://plugins.iem.at/), you can even change the 
channel count dynamically and the plugins will automatically adjust the 
ambisonics order.


In the meantime I have also updated the release notes.

Again, please test and report any issues!

Christof

On 05.02.2024 13:42, Christof Ressi wrote:


Of course, [vstplugin~] is also available on Deken!

On 05.02.2024 13:41, Christof Ressi wrote:


Hi,

here is a first test release of [vstplugin~] v0.6: 
https://git.iem.at/pd/vstplugin/-/releases/v0.6-test1


NOTE: previous versions would hide certain (non-automatable) 
parameters in VST3 plugins. This has been fixed, but as a consequence 
parameter indexes might have changed. [vstplugin~] prints a warning 
for every plugin that is affected by this change!


Please test and report any issues at Issues · Pure Data libraries / 
vstplugin · GitLab <https://git.iem.at/pd/vstplugin/-/issues>.


Have fun!

Christof


___
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___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] IEM Music Residency Program 2024 - Call for Applications

[Christof Ressi]

It should probably be mentioned that this is a *paid* residency. (The 
salary is only mentioned in the 'official' call.)


On 09.02.2024 14:18, IOhannes m zmölnig wrote:

(sorry for cross-posting / please distribute)

The IEM – Institute of Electronic Music and Acoustics – in Graz, 
Austria is happy to announce its call for its 2024 residency program.


Artistic Research Residency

The residency is aimed at individuals wishing to pursue an artistic 
research project in close collaboration with an IEM staff member and 
related to the research fields of the IEM:


*  Algorithmic Composition
*  Algorithmic Experimentation
*  Audio-Visuality
*  Dynamical Systems
*  Experimental Game Design
*  Live Coding
*  Sonic Interaction Design
*  Spatialization/higher-order Ambisonics
*  Standard and non-standard Sound Synthesis

Duration of residency: 4 months
Start date: September 1st 2024 (negotiable)

APPLICATION DEADLINE: March 31th 2024


Please reply to the official call by KUG for an University Assistant:
https://go.iem.at/residency24 (in German and English)

The Institute:
The Institute of Electronic Music and Acoustics is a department of the 
University of Music and Performing Arts Graz founded in 1965. It is a 
leading institution in its field, with more than 35 staff members of 
researchers and artists. IEM offers education to students in 
composition and computer music, sound engineering, sound design, 
contemporary music performance, and musicology. It is well connected 
to the University of Technology, the University of Graz as well as to 
the University of Applied Sciences Joanneum through three joint study 
programs.


The project results will be released through the Institute's own Open 
CUBE and Signale concert series, as well as through various 
collaborations with international artists and institutions.


What we expect from applicants:
- A project proposal that adds new perspectives to the Institute's 
activities and resonates well with the interests of IEM.

- Willingness to work on-site in Graz for the most part of the Residency.
- Willingness to exchange and share ideas, knowledge and results with 
IEM staff members and students, and engage in scholarly discussions.

- The ability to work independently within the Institute.
- A dissemination strategy as part of the project proposal that 
ensures the publication of the work, or documentation thereof, in a 
suitable format. This could be achieved for example through the 
release of media, journal or conference publication, a project 
website, or other means that help to preserve the knowledge gained 
through the Residency and make it available to the public.
- A public presentation as e.g. a concert or installation, which 
presents the results of the Residency.


What we offer:
- 24/7 access to the facilities of the IEM.
- Exchange with competent and experienced staff members.
- A desk in a shared office space for the entire period and access to 
studios including the CUBE [1], according to availability.
- Extensive access to the studios of the IEM during the period from 
July 1st until end of September.

- access to the IKOsahedron loudspeaker [2]
- access to the “Autoklavierspieler” [3]
- infrared motion tracking systems
- Regular possibilities for contact and exchange with peers from 
similar or other disciplines.
- Concert and presentation facilities (CUBE 30 channel loudspeaker 
concert space).


What we cannot offer to the successful applicant:
- We can not provide any housing.
- We also cannot provide continuous assistance and support, although 
the staff is generally willing to help where possible.

- We can not host artist duos or groups, because of spatial limitations.
- We can not offer any additional financial support for travel or 
material expenses.


Feel free to contact mailto:reside...@iem.at if you have any questions.

[1] The Cube has a 30-channel loudspeaker system
[2] https://iko.sonible.com/
[3] https://algo.mur.at/projects/autoklavierspieler


---

IEM Music Residency Program 2024 - Call for Applications
University of Music and Performing Arts Graz (KUG)
https://iem.at

___
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




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

Re: [PD] [vstplugin~] v0.6-test1

[Christof Ressi]

Of course, [vstplugin~] is also available on Deken!

On 05.02.2024 13:41, Christof Ressi wrote:


Hi,

here is a first test release of [vstplugin~] v0.6: 
https://git.iem.at/pd/vstplugin/-/releases/v0.6-test1


NOTE: previous versions would hide certain (non-automatable) 
parameters in VST3 plugins. This has been fixed, but as a consequence 
parameter indexes might have changed. [vstplugin~] prints a warning 
for every plugin that is affected by this change!


Please test and report any issues at Issues · Pure Data libraries / 
vstplugin · GitLab <https://git.iem.at/pd/vstplugin/-/issues>.


Have fun!

Christof


___
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

[PD] [vstplugin~] v0.6-test1

[Christof Ressi]

Hi,

here is a first test release of [vstplugin~] v0.6: 
https://git.iem.at/pd/vstplugin/-/releases/v0.6-test1


NOTE: previous versions would hide certain (non-automatable) parameters 
in VST3 plugins. This has been fixed, but as a consequence parameter 
indexes might have changed. [vstplugin~] prints a warning for every 
plugin that is affected by this change!


Please test and report any issues at Issues · Pure Data libraries / 
vstplugin · GitLab .


Have fun!

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

[Christof Ressi]

Thanks for your kind words, Roman! Your input and feedback has been 
extremely valuable!


On 30.01.2024 16:55, Roman Haefeli wrote:

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


___
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] AOO v2.0-pre3 release

[Christof Ressi]

Thanks!

"OSCGroups" has actually been an inspiration for some of AOO's features, 
in particular the concept of groups and users (although my 
implementation is very different).


Christof

On 30.01.2024 02:45, Phil Stone wrote:

This looks fantastic, Christof. My group has been using Ross Bencina’s 
venerable “OSCGroups” for nearly twenty years, but this is just another level.


On Jan 29, 2024, at 4:47 PM, Christof Ressi  wrote:

I also want to point out that the IEM is running a public AOO server: "vrr.iem.at 
7078"

I will shut down the old AOO server ("vrr.iem.at 7077") in the near future.

On 30.01.2024 01:42, Christof Ressi wrote:

Dear list,

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!

AOO ("audio over OSC") is a low-latency peer-to-peer audio streaming and 
messaging library. It works both in local networks and the public internet! See 
https://git.iem.at/cm/aoo#aoo-audio-over-osc-v20-test3 for a more exhaustive feature list.

For bug reports and feature requests, please use the issue tracker: 
https://git.iem.at/cm/aoo/-/issues

---

Officially, this is still a pre-release, but the underlying OSC protocol and 
the Pd objects can be considered stable. (I still need to tweak the C/C++ API). 
At this point I want to avoid any breaking changes unless they are really 
justified.

Have fun!

Christof




___
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




___
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

[Christof Ressi]

I also want to point out that the IEM is running a public AOO server: 
"vrr.iem.at 7078"


I will shut down the old AOO server ("vrr.iem.at 7077") in the near future.

On 30.01.2024 01:42, Christof Ressi wrote:

Dear list,

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!


AOO ("audio over OSC") is a low-latency peer-to-peer audio streaming 
and messaging library. It works both in local networks and the public 
internet! See https://git.iem.at/cm/aoo#aoo-audio-over-osc-v20-test3 
for a more exhaustive feature list.


For bug reports and feature requests, please use the issue tracker: 
https://git.iem.at/cm/aoo/-/issues


---

Officially, this is still a pre-release, but the underlying OSC 
protocol and the Pd objects can be considered stable. (I still need to 
tweak the C/C++ API). At this point I want to avoid any breaking 
changes unless they are really justified.


Have fun!

Christof




___
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

[PD] AOO v2.0-pre3 release

[Christof Ressi]

Dear list,

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!


AOO ("audio over OSC") is a low-latency peer-to-peer audio streaming and 
messaging library. It works both in local networks and the public 
internet! See https://git.iem.at/cm/aoo#aoo-audio-over-osc-v20-test3 for 
a more exhaustive feature list.


For bug reports and feature requests, please use the issue tracker: 
https://git.iem.at/cm/aoo/-/issues


---

Officially, this is still a pre-release, but the underlying OSC protocol 
and the Pd objects can be considered stable. (I still need to tweak the 
C/C++ API). At this point I want to avoid any breaking changes unless 
they are really justified.


Have fun!

Christof




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

Re: [PD] receive UDP message from 224.0.0.1

[Christof Ressi]

> When we did the networking handling refactoring, I'm pretty sure we 
tested this on Windows.


Back then it did work :) But this was on Windows 7. Will test again on 
Windows 10.


Christof

On 12.01.2024 16:25, Dan Wilcox wrote:
Ok, this would be a bug then. It *should* work but perhaps we need an 
additional flag when setting up the socket on Windows. When we did the 
networking handling refactoring, I'm pretty sure we tested this on 
Windows. What do you think Christof?


Do the multicast examples in the netsend and netrecieve help files 
work? For example, you start the multicast receiver in one and send to 
it form the other help?



On Jan 11, 2024, at 11:15 PM, pd-list-requ...@lists.iem.at wrote:

Message: 4
Date: Thu, 11 Jan 2024 22:15:00 +0100
From: Jo?o Pais 
Cc: Pd-List 
Subject: Re: [PD] receive UDP message from 224.0.0.1
Message-ID: <1d26753e-b344-4722-8b0d-3b86f8014...@gmail.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"



Are you opening with the following message?

[ listen 57120?224.0.0.1 <
|
[ netreceive -u -b]

The address is within the multicast range, so it needs to be given to
netreceive in addition to the port.

It doesn't work in windows, but it does in ubuntu - although windows is
my main work system. (latest Pd version on both)



Dan Wilcox
danomatika.com 
robotcowboy.com 


___
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] open multiple files limits?

[Christof Ressi]

Hi,


looks like there's a size limit for the callback message. I'd suggest to 
open a ticket on GitHub!



Christof


On 11.01.2024 15:20, Remmy Canedo wrote:

Hello,

I'm trying to open 189 files with

[bang(
|
[openpanel 2]

file names are 1.wav, 2.wav, 3.wav... 189.wav with different sizes 
from 48,2 to 343,5 KiB


when I use short paths, like home/user/Music/test_samples I'm able to 
open 112 files
with long paths, for ex: 
home/user/FOLDER_1/Folder_002/Folder_3/folder_4/folder_5/test_samples 
I can only open 53 files max.

more than that, it gives me an error in console:
av: no such object

If anyone can explain why this happens and how to overcome these 
limits I would be very grateful.


thanks in advance!
remmy

Pd version 0.52.1
System:
Kernel: 5.15.0-91-lowlatency x86_64 bits: 64 compiler: gcc v: 11.4.0 
Desktop: Xfce 4.18.1
tk: Gtk 3.24.33 wm: xfwm dm: LightDM Distro: Linux Mint 21.2 Victoria 
base: Ubuntu 22.04 jammy









___
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] receive UDP message from 224.0.0.1

[Christof Ressi]

I don't use SC, but I'll check anyway if some years ago I installed it 
and then forgot about it.
Ok, then this was a red herring. That's a pretty strange coincidence, 
though. Anyway, sclang.exe must not only be installed, but also *running*.


However, you can check if some other program already uses port 57120! On 
Windows you can do this by running "netstat -abno" in cmd.exe as Admin.


Also, have you tried with other port numbers?

Christof

On 11.01.2024 10:34, João Pais wrote:
I don't use SC, but I'll check anyway if some years ago I installed it 
and then forgot about it.


It is a multicast address - I might be able to change it to the normal 
broadcast address, but I wouldn't count on it. So for now, it's better 
to assume that this can't be changed.


Hmmm... 57120 happens to be the default port of sclang (the
SuperCollider language interpreter). Could it be that sclang(.exe)
is running? Check the task manager to be sure.

Explanation: Generally, only one application can listen to a port
at a time. Normally, applications will just refuse to bind to
ports that are already taken. However, Pd sets the SO_REUSEADDR
socket option, which allows to bind to an existing port.

This is needed for TCP sockets, because they typically "linger"
for a while after you close them. If you close and immediately
reopen a patch, [netreceive] would refuse to bind.

However, we probably should /not/ set SO_REUSEADDR for UDP sockets
because it doesn't do anything useful. On the contrary, it just
causes confusion because [netreceive -u] does not post an error if
the port is already taken.

Christof

On 10.01.2024 23:08, João Pais wrote:

Hi everyone,

I'm trying to receive some UDP data from a mobile device into Pd.
The data arrives in the computer (windows or ubuntu), here is a
description from wireshark:

Frame 173: 90 bytes on wire (720 bits), 90 bytes captured (720
bits) on interface
\Device\NPF_{2ADD2685-ACB9-4C51-B708-F1F62FAE86C7}, id 0
Ethernet II, Src: XiaomiCommun_1d:0e:fd (4c:e0:db:1d:0e:fd), Dst:
IPv4mcast_01 (01:00:5e:00:00:01)
Internet Protocol Version 4, Src: 192.168.178.34, Dst: 224.0.0.1
User Datagram Protocol, Src Port: 43641, Dst Port: 57120
Data (48 bytes)


But with [netreceive -u -b 57120] (or any other options to
netreceive) no data comes into Pd. Does anyone have any
suggestion on how to receive the data?

When is sent to 224.0.0.1, the data gets into the computer but
not into Pd. But if other udp data is sent to the broadcast ip
(192.168.178.255) from the same device, it does get also into Pd.

Frame 31: 66 bytes on wire (528 bits), 66 bytes captured (528
bits) on interface
\Device\NPF_{2ADD2685-ACB9-4C51-B708-F1F62FAE86C7}, id 0
Ethernet II, Src: XiaomiCommun_1d:0e:fd (4c:e0:db:1d:0e:fd), Dst:
Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 192.168.178.34, Dst:
192.168.178.255
User Datagram Protocol, Src Port: 42797, Dst Port: 57120
Data (24 bytes)

Best,

Joao




___
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


___
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] receive UDP message from 224.0.0.1

[Christof Ressi]

Hmmm... 57120 happens to be the default port of sclang (the 
SuperCollider language interpreter). Could it be that sclang(.exe) is 
running? Check the task manager to be sure.


Explanation: Generally, only one application can listen to a port at a 
time. Normally, applications will just refuse to bind to ports that are 
already taken. However, Pd sets the SO_REUSEADDR socket option, which 
allows to bind to an existing port.


This is needed for TCP sockets, because they typically "linger" for a 
while after you close them. If you close and immediately reopen a patch, 
[netreceive] would refuse to bind.


However, we probably should /not/ set SO_REUSEADDR for UDP sockets 
because it doesn't do anything useful. On the contrary, it just causes 
confusion because [netreceive -u] does not post an error if the port is 
already taken.


Christof

On 10.01.2024 23:08, João Pais wrote:

Hi everyone,

I'm trying to receive some UDP data from a mobile device into Pd. The 
data arrives in the computer (windows or ubuntu), here is a 
description from wireshark:


Frame 173: 90 bytes on wire (720 bits), 90 bytes captured (720 bits) 
on interface \Device\NPF_{2ADD2685-ACB9-4C51-B708-F1F62FAE86C7}, id 0
Ethernet II, Src: XiaomiCommun_1d:0e:fd (4c:e0:db:1d:0e:fd), Dst: 
IPv4mcast_01 (01:00:5e:00:00:01)

Internet Protocol Version 4, Src: 192.168.178.34, Dst: 224.0.0.1
User Datagram Protocol, Src Port: 43641, Dst Port: 57120
Data (48 bytes)


But with [netreceive -u -b 57120] (or any other options to netreceive) 
no data comes into Pd. Does anyone have any suggestion on how to 
receive the data?


When is sent to 224.0.0.1, the data gets into the computer but not 
into Pd. But if other udp data is sent to the broadcast ip 
(192.168.178.255) from the same device, it does get also into Pd.


Frame 31: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on 
interface \Device\NPF_{2ADD2685-ACB9-4C51-B708-F1F62FAE86C7}, id 0
Ethernet II, Src: XiaomiCommun_1d:0e:fd (4c:e0:db:1d:0e:fd), Dst: 
Broadcast (ff:ff:ff:ff:ff:ff)

Internet Protocol Version 4, Src: 192.168.178.34, Dst: 192.168.178.255
User Datagram Protocol, Src Port: 42797, Dst Port: 57120
Data (24 bytes)

Best,

Joao




___
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

[PD] Wrong macOS app for 0.54-1

[Christof Ressi]

Hi,

I just noticed that the section "Pd compiled for older system" in 
http://msp.ucsd.edu/software.html actually contains macOS versions of Pd 
0.53-1 instead of Pd 0.54-1. I just discovered this because I download 
the .tar.gz files in my CI pipeline; I tried to increase the Pd version 
to 0.54-1 and got an error...


Christof




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

[PD] vstplugin~ 0.5.4 macOS ARM binaries

[Christof Ressi]

Hi,

I just wanted to let you know that I have finally uploaded macOS 
universal binaries (arm64 + x86_64) for [vstplugin~] v0.5.4 to Deken.


The binaries are ad-hoc signed, so they should load without requiring 
any security dances. If you encounter any problems, please let me know. 
(If possible, use the issue tracker: 
https://git.iem.at/pd/vstplugin/-/issues)


Best,

Christof




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

Re: [PD] help needed: "conditional" help patches

[Christof Ressi]

On 11.12.2023 16:10, IOhannes m zmoelnig wrote:

the simplest check would just be whether the filename of the 
containing patch ends with "-help.pd"


I actually had this thought, but rejected it for being too gross :-D

Also, it does not really work because [aoo_send~ 2] and [aoo_send~ -m 2] 
have a different number of signal inlets, so I would get errors about 
failed connections. (That was another nasty aspect I forgot to mention!) 
Also, the help patch naturally contains other multichannel objects, most 
notably [snake~], which don't exist in older Pd versions. I really need 
to prevent the whole (sub)patch from being loaded.


Christof




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

Re: [PD] help needed: "conditional" help patches

[Christof Ressi]

On 12/11/23 15:29, Christof Ressi wrote:
Ok, I have a come up with the following solution: I moved the 
multichannel section into a dedicated patch and open it with [;pd 
open   1( when the user clicks a bang button in the main 
help patch. It's not perfect, but kind of works for my purposes.


so the user only gets the error if they click on the bang?
hmm.
Yes, it is not perfect. This could be avoided, if Pd had a way to query 
the version at runtime (see 
https://github.com/pure-data/pure-data/issues/928). I thought about 
adding a (private) message to the AOO objects that returns the actual Pd 
version via sys_getversion(), but this seems a bit overkill.


- personally i wouldn't care to much about error messages in help 
patches (as in: going through hoops in order to avoid them). 

I do...
since in this case you control the actual error message make sure that 
it is friendly enough (e.g. just telling people that they will need a 
newer version of Pd in order to use this cool feature) - i strongly 
believe that we can expect people to actually read and understand an 
error message (and not just seek help just because "lines were red"). 
it's not that Pd's error messages are very obtrusive)


The error message itself is friendly, but in this case the user did 
nothing wrong - they just opened a help patch! - so I would *really* 
like to avoid them.


you could create two help patches and in the multichannel version 
*only* document the multichannel features and include the 
non-multichannel help patch as an ordinary object (probably with some 
"auto open" code. that way you wouldn't have to duplicate the common 
documentation. 


Interesting. The big disadvantage is that the roles are reversed: what 
should be a subpatch is now the root window, so when the user tries to 
close it, it closes the whole help patch... So I guess I'd rather prefer 
my current solution.


But thanks for your input!

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

Re: [PD] help needed: "conditional" help patches

[Christof Ressi]

Ok, I have a come up with the following solution: I moved the 
multichannel section into a dedicated patch and open it with [;pd open 
  1( when the user clicks a bang button in the main help 
patch. It's not perfect, but kind of works for my purposes.


I am still wondering if anyone has run into the same issue and found 
other solutions.


Christof

On 05.12.2023 22:00, Christof Ressi wrote:


Hi,

I have a library with /optional /multi-channel support. If you try to 
create the object with the "-m" flag and Pd does not have 
multi-channel support, it would print an error message. This works all 
fine, but there's a tricky problem with the help patches. Of course, I 
want to document the multi-channel feature, but I don't want the help 
patch to print errors when loaded in older Pd versions.


The only solution I see at the moment is to have two version of the 
help patch and then register the appropriate version in the setup 
function with "class_sethelpsymbol". However, this would be a 
maintenance nightmare. Also, the help patches would obviously need to 
have different names, so only one of them would match the name of the 
object.


Has anyone run into a similar situation? Any ideas?

Christof



___
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] Latency question (non-audio/midi/osc)

[Christof Ressi]

Is it (still) the case that Pd's midi buffer is connected/synced with 
the audio buffer? (Sorry if any terminology incorrect). 
Yes, MIDI messages are artificially delayed to match the additional 
latency caused by the ringbuffer (see "Delay" entry in audio settings 
resp. "-audiobuf" command line option).


At least in my scheduler-fix branch 
(https://github.com/pure-data/pure-data/pull/1756), this does not happen 
with "callbacks" enabled. However, this does not really help as you 
would typically need to use a larger hardware buffer size (confusingly 
called "blocksize") - which would again increase MIDI latency - and also 
increase MIDI jitter!


It would be great if the MIDI delay could be disabled globally, or even 
better - on a per-object or per-event basis! Would you mind opening a 
feature request on GitHub?


Christof

On 11.12.2023 13:34, Sam Ross wrote:

Hello list,

Is it (still) the case that Pd's midi buffer is connected/synced with 
the audio buffer? (Sorry if any terminology incorrect).


If this is the case, is it correct that the best way to get lowest 
latency control signals is to run control data in a separate instance 
that is removed from any audio processing, with the audio settings set 
for as low a latency as possible? So, delay 0 ms, I presume? And would 
altering the sample rate and block size also have an effect?


Thanks for any help you can give in assisting my understanding.
Sam.




___
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

[PD] help needed: "conditional" help patches

[Christof Ressi]

Hi,

I have a library with /optional /multi-channel support. If you try to 
create the object with the "-m" flag and Pd does not have multi-channel 
support, it would print an error message. This works all fine, but 
there's a tricky problem with the help patches. Of course, I want to 
document the multi-channel feature, but I don't want the help patch to 
print errors when loaded in older Pd versions.


The only solution I see at the moment is to have two version of the help 
patch and then register the appropriate version in the setup function 
with "class_sethelpsymbol". However, this would be a maintenance 
nightmare. Also, the help patches would obviously need to have different 
names, so only one of them would match the name of the object.


Has anyone run into a similar situation? Any ideas?

Christof

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

Re: [PD] Relative Db measurement

[Christof Ressi]

I'rather be interested in the difference between [samphold~] and
[snapshot~]. They seem to almost do the same thing to me.
The only difference is that [samphold~] is audio rate and [snapshot~] is 
control rate.


Christof

On 04.11.2023 10:05, Peter P. wrote:

* Andy Farnell  [2023-11-04 09:49]:
[...]

confused about what is the best way to do that, the choices being
[samphold] and [env]. So I'd also be interested in the best (most
accurate) answer.

Andy, [samphold] as well as [snapshot~] do give you the amplitude value
of one single sample, which for audio signals is often in the range
between -1 and 1. [env~] will give you an dBRMS value (the mean of all
absolute amplitudes over a certain time window, converted to dB.

Was that your question?

I'rather be interested in the difference between [samphold~] and
[snapshot~]. They seem to almost do the same thing to me.

best, P



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




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

Re: [PD] off topic: congrats Miller for the Silver Lion award from La Biennale di Venezia

[Christof Ressi]

Congrats Miller! More than deserved!

On 21.10.2023 04:17, Alexandre Torres Porres wrote:

see https://www.labiennale.org/en/music/2023/silver-lion

Cheers for Miller <3

___
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] round off the corners of a [line] movement?

[Christof Ressi]

Now I am not sure if [line"] was supposed to be [line~]... Just in case, 
here's a signal version called [cline~].


Christof

On 27.09.2023 14:51, Christof Ressi wrote:
[line] outputs a linear ramp, so you just need to apply a transfer 
function to get the behavior you want. For example, if you want a 
gradual start and gradual, you could use the second half of a cosine 
wave.


I have an abstraction called [cline] that supports various shapes (see 
attachment).


Christof

On 26.09.2023 20:06, Peter P. wrote:

Hi list,

often when I use [line¨] to make frequency glissandi, the point when the
ramp starts, and the point where it ends, appear as very sudden events
to my ears. I am wondering if there is an easy way to gradually speed up
the ramp when it starts, and slow it down before it reaches its target
value?
The only way I can think of so far is to model such a behavior with two
masses connected by an elastic link using the pmpd library. But a
vanilla way would be very interesting too!

Thanks in advance for all ideas and pointers!
cheersz, Peter



___
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#N canvas 747 262 842 546 10;
#X obj 3 181 line~;
#X obj 130 140 snapshot~;
#X obj 30 359 outlet~;
#X obj 58 -8 inlet;
#X obj 4 205 -~ 0;
#X obj 82 121 -;
#X obj 4 234 /~ 1;
#X obj 4 295 *~ 1;
#X obj 30 326 +~ 0;
#X obj 62 90 t l f b;
#X obj 10 151 spigot;
#N canvas 256 342 893 547 transfer 0;
#X obj 62 61 inlet~;
#X obj 117 61 r \$0-transfer;
#N canvas 309 228 1087 458 exp 0;
#X obj 358 196 exp~;
#X obj 419 191 exp;
#X obj 354 73 inlet~;
#X obj 359 162 *~ 1;
#X obj 357 232 -~ 1;
#X obj 420 227 - 1;
#X obj 355 270 /~ 1;
#X obj 354 341 outlet~;
#X text 122 50 normalized natural exponential function;
#X obj 405 72 r \$0-arg;
#X obj 412 128 * -1;
#X obj 505 126 switch~;
#X obj 504 74 inlet;
#X obj 504 96 == 2;
#X connect 0 0 4 0;
#X connect 1 0 5 0;
#X connect 2 0 3 0;
#X connect 3 0 0 0;
#X connect 4 0 6 0;
#X connect 5 0 6 1;
#X connect 6 0 7 0;
#X connect 9 0 10 0;
#X connect 10 0 3 1;
#X connect 10 0 1 0;
#X connect 12 0 13 0;
#X connect 13 0 11 0;
#X restore 165 243 pd exp;
#X obj 134 303 outlet~;
#N canvas 0 50 450 300 pow 0;
#X obj 87 130 inlet~;
#X obj 106 213 outlet~;
#X obj 107 176 pow~ 1;
#X msg 148 131 1;
#X obj 148 76 max 0;
#X obj 148 104 select 0;
#X obj 148 45 r \$0-arg;
#X obj 246 134 switch~;
#X obj 248 82 inlet;
#X obj 249 107 == 1;
#X connect 0 0 2 0;
#X connect 2 0 1 0;
#X connect 3 0 2 1;
#X connect 4 0 5 0;
#X connect 5 0 3 0;
#X connect 5 1 2 1;
#X connect 6 0 4 0;
#X connect 8 0 9 0;
#X connect 9 0 7 0;
#X restore 107 244 pd pow;
#X text 286 89 missing or invalid argument is set to 'lin' (0);
#N canvas 266 122 787 443 cos 0;
#X obj 94 25 inlet~;
#X obj 91 335 outlet~;
#X obj 251 24 inlet;
#X obj 90 241 cos~;
#X obj 93 186 *~ 1;
#X obj 91 212 +~ 0;
#X obj 91 270 +~ 0;
#X obj 91 300 *~ 1;
#X obj 164 165 unpack f f f f;
#X msg 184 108 0.25 -0.25 0 1;
#X msg 204 139 0.25 0.5 1 1;
#X msg 173 81 0.5 0.5 1 0.5;
#X obj 170 29 r \$0-arg;
#X obj 168 56 sel 0 1 2;
#X text 307 48 cos 0: second half of a cosine wave (s-shape) \; cos
1: last quarter of a cosine wave (slow rise) \; cos 2: third quarter
of a cosine wave (fast rise) \; 'reset' message simply goes through
the rejection outlet of select and sets output of cos~ to zero.;
#X obj 264 330 switch~;
#X obj 264 286 == 3;
#X connect 0 0 4 0;
#X connect 2 0 16 0;
#X connect 3 0 6 0;
#X connect 4 0 5 0;
#X connect 5 0 3 0;
#X connect 6 0 7 0;
#X connect 7 0 1 0;
#X connect 8 0 4 1;
#X connect 8 1 5 1;
#X connect 8 2 6 1;
#X connect 8 3 7 1;
#X connect 9 0 8 0;
#X connect 10 0 8 0;
#X connect 11 0 8 0;
#X connect 12 0 13 0;
#X connect 13 0 11 0;
#X connect 13 1 9 0;
#X connect 13 2 10 0;
#X connect 16 0 15 0;
#X restore 224 244 pd cos;
#X obj 117 91 select lin pow exp cos;
#X obj 225 26 r \$0-arg;
#X obj 187 117 demux;
#X obj 225 55 != 0;
#X text 284 114 exp with argument 0 is routet to 'lin';
#X text 199 170 switch off what you don't need;
#X obj 64 244 *~;
#X obj 165 167 t f;
#X msg 126 138 0;
#X msg 163 140 1;
#X msg 216 140 2;
#X msg 253 139 3;
#X obj 79 200 == 0;
#X connect 0 0 4 0;
#X connect 0 0 2 0;
#X connect 0 0 6 0;
#X connect 0 0 13 0;
#X connect 1 0 7 0;
#X connect 2 0 3 0;
#X connect 4 0 3 0;
#X connect 6 0 3 0;
#X connect 7 0 15 0;
#X connect 7 1 16 0;
#X connect 7 2 9 0;
#X connect 7 3 18 0;
#X connect 7 4 15 0;
#X connect 8 0 10 0;
#X connect 9 0 15 0;
#X connect 9 1 17 0;
#X connect 10 0 9 1;
#X connect 13 0 3 0;
#X connect 14 0 4 1;
#X connect 14 0 2 1;
#X connect 14 0 6 1;
#X connect 14 0 19 0;
#X connect 15 0 14 0;
#X connect 16 0 14 0;
#X connect 17 0 14 0;
#X connect 18 0 14 0;
#X connect 19 0 13 1;
#X restore 4 265 pd transfer;
#N can

Re: [PD] round off the corners of a [line] movement?

[Christof Ressi]

[line] outputs a linear ramp, so you just need to apply a transfer 
function to get the behavior you want. For example, if you want a 
gradual start and gradual, you could use the second half of a cosine wave.


I have an abstraction called [cline] that supports various shapes (see 
attachment).


Christof

On 26.09.2023 20:06, Peter P. wrote:

Hi list,

often when I use [line¨] to make frequency glissandi, the point when the
ramp starts, and the point where it ends, appear as very sudden events
to my ears. I am wondering if there is an easy way to gradually speed up
the ramp when it starts, and slow it down before it reaches its target
value?
The only way I can think of so far is to model such a behavior with two
masses connected by an elastic link using the pmpd library. But a
vanilla way would be very interesting too!

Thanks in advance for all ideas and pointers!
cheersz, Peter



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list#N canvas 601 170 834 486 10;
#X obj 138 25 inlet;
#X obj 159 155 -;
#X obj 136 120 t l f b;
#N canvas 307 136 893 547 transfer 0;
#X obj 117 61 r \$0-transfer;
#X msg 117 122 0;
#X msg 147 122 1;
#X msg 215 165 2;
#X msg 228 122 3;
#N canvas 309 228 1087 458 exp 0;
#X obj 419 191 exp;
#X obj 420 227 - 1;
#X text 122 50 normalized natural exponential function;
#X obj 405 72 r \$0-arg;
#X obj 412 128 * -1;
#X obj 355 72 inlet;
#X obj 354 303 outlet;
#X obj 358 162 * 1;
#X obj 359 196 exp;
#X obj 357 232 - 1;
#X obj 355 270 / 1;
#X connect 0 0 1 0;
#X connect 1 0 10 1;
#X connect 3 0 4 0;
#X connect 4 0 0 0;
#X connect 4 0 7 1;
#X connect 5 0 7 0;
#X connect 7 0 8 0;
#X connect 8 0 9 0;
#X connect 9 0 10 0;
#X connect 10 0 6 0;
#X restore 145 260 pd exp;
#N canvas 0 50 450 300 pow 0;
#X msg 148 131 1;
#X obj 148 76 max 0;
#X obj 148 104 select 0;
#X obj 148 45 r \$0-arg;
#X obj 87 130 inlet;
#X obj 107 176 pow 1;
#X obj 106 212 outlet;
#X connect 0 0 5 1;
#X connect 1 0 2 0;
#X connect 2 0 0 0;
#X connect 2 1 5 1;
#X connect 3 0 1 0;
#X connect 4 0 5 0;
#X connect 5 0 6 0;
#X restore 114 228 pd pow;
#X msg 266 122 0;
#X text 300 122 missing or invalid argument is set to 'lin' (0);
#N canvas 769 284 787 443 cos 0;
#X obj 164 165 unpack f f f f;
#X msg 184 108 0.25 -0.25 0 1;
#X msg 204 139 0.25 0.5 1 1;
#X msg 173 81 0.5 0.5 1 0.5;
#X msg 236 232 0;
#X obj 167 21 r \$0-arg;
#X obj 168 56 sel 0 1 2;
#X obj 94 24 inlet;
#X obj 92 278 cos;
#X obj 93 307 + 0;
#X obj 93 337 * 1;
#X obj 93 219 + 0;
#X obj 93 186 * 1;
#X obj 96 374 outlet;
#X obj 93 248 * 6.28319;
#X connect 0 0 12 1;
#X connect 0 1 11 1;
#X connect 0 2 9 1;
#X connect 0 3 10 1;
#X connect 1 0 0 0;
#X connect 2 0 0 0;
#X connect 3 0 0 0;
#X connect 4 0 10 1;
#X connect 5 0 6 0;
#X connect 6 0 3 0;
#X connect 6 1 1 0;
#X connect 6 2 2 0;
#X connect 6 3 4 0;
#X connect 7 0 12 0;
#X connect 8 0 9 0;
#X connect 9 0 10 0;
#X connect 10 0 13 0;
#X connect 11 0 14 0;
#X connect 12 0 11 0;
#X connect 14 0 8 0;
#X restore 176 300 pd cos;
#X obj 117 91 select lin pow exp cos;
#X obj 311 59 r \$0-arg;
#X obj 182 122 demux;
#X obj 311 88 != 0;
#X text 355 89 exp with argument 0 is routet to 'lin';
#X obj 87 394 outlet;
#X obj 63 61 inlet;
#X obj 83 178 demux 0 1 2 3;
#X connect 0 0 10 0;
#X connect 1 0 17 1;
#X connect 2 0 17 1;
#X connect 3 0 17 1;
#X connect 4 0 17 1;
#X connect 5 0 15 0;
#X connect 6 0 15 0;
#X connect 7 0 17 1;
#X connect 9 0 15 0;
#X connect 10 0 1 0;
#X connect 10 1 2 0;
#X connect 10 2 12 0;
#X connect 10 3 4 0;
#X connect 10 4 7 0;
#X connect 11 0 13 0;
#X connect 12 0 1 0;
#X connect 12 1 3 0;
#X connect 13 0 12 1;
#X connect 16 0 17 0;
#X connect 17 0 15 0;
#X connect 17 1 6 0;
#X connect 17 2 5 0;
#X connect 17 3 9 0;
#X restore 116 244 pd transfer;
#N canvas 542 443 817 556 arg 0;
#X obj 112 42 inlet;
#X obj 111 72 route set;
#X obj 195 6 loadbang;
#X obj 163 274 s \$0-arg;
#X obj 49 273 s \$0-transfer;
#X obj 184 73 symbol \$1;
#X obj 259 73 \$2;
#X obj 163 241 f;
#X obj 196 39 t b b;
#X obj 177 175 route bang float;
#X msg 177 200 0;
#X obj 183 108 pack s f;
#X obj 100 205 t s b;
#X obj 110 136 list split 1;
#X connect 0 0 1 0;
#X connect 1 0 13 0;
#X connect 2 0 8 0;
#X connect 5 0 11 0;
#X connect 6 0 11 1;
#X connect 7 0 3 0;
#X connect 8 0 5 0;
#X connect 8 1 6 0;
#X connect 9 0 10 0;
#X connect 9 1 7 1;
#X connect 10 0 7 1;
#X connect 11 0 13 0;
#X connect 12 0 4 0;
#X connect 12 1 7 0;
#X connect 13 0 12 0;
#X connect 13 1 9 0;
#X restore 282 84 pd arg;
#X text 296 52 anything ("set ...");
#X text 22 39 list \; (target \, time);
#X text 340 269 note: it's best to change the shape of the transfer
function when starting a new ramp and not in the middle of an ongoing
ramp. with this technique you can easily design envelope generators
with individual shapes for each section.;
#X text 342 127 use "set" messages to change arguments dynamically:
;
#X text 341 79 creation arguments: \; 1) 

Re: [PD] maxlib on OSX version?

[Christof Ressi]

 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.


Personally, I have many projects that use [maxlib/gauss]. There is 
probably a replacement *somewhere* but I didn't bother.


"mrpeach" also has [midifile], which I use regularly. Is there are good 
(and stable) replacement object?



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


Someone might pick them up and start maintaining them (which has 
happenend in the past). In fact, [mrpeach] has been maintained until 
recently. (Martin Peach has passed away two years ago, sadly.)


In general, there is nothing wrong with making older library versions 
available for newer platforms. After all, some projects pin their 
dependencies to specific versions and don't want to risk updates, as 
they might cause regressions.



  I, personally, prefer to rather keep things clear and help people do the 
migration.


While I agree that *new* projects should probably try to migrate, there 
are lots of *existing* projects that rely on these libraries. People 
might want to run these existing projects on newer platforms, but they 
can't afford or don't have the skills to migrate, so it would be nice if 
the libraries were available on Deken.


Christof


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


___
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] maxlib on OSX version?

[Christof Ressi]

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


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

Re: [PD] pd external build problem

[Christof Ressi]

Hi,

this is a known issue with recent GCC versions. Just don't compile with 
"-Werror" or disable the warning with "-Wno-cast-function-type".


Did you enable "-Werror" yourself? Generally, it's not a good idea to 
enable "-Werror" by default in your build system because new compiler 
versions tend to introduce new warnings which in turn may break the 
build process.


Christof

On 17.09.2023 15:33, ub wrote:

hey list,


i was trying to compile a pd-external which i made some time ago and 
found that gcc issues a warning – turned into an error – regarding the 
type of t_newmethod.


 error: cast between incompatible function types from ‘void * 
(*)(t_symbol *, int,  t_atom *)’ {aka ‘void * (*)(struct _symbol *, 
int,  struct _atom *)’} to ‘void * (*)(void)’ 
[-Werror=cast-function-type]

  478 |  (t_newmethod) zmq_new,

now i checked with the external howto on github and couldn't find 
anything wrong with the code.


the way i understand it, the type should be void * (*)(void) if i 
would not declare an inlet. since i do declare inlets with A_GIMME, it 
is my understanding that the function type of t_newmethod should be 
void * (*)(t_symbol *, int,  t_atom *)


the external loads and seems to run fine, when built without -Werror.

maybe someone can help me fix this.


my class constructor is declared as:

static void *zmq_new(t_symbol *s, int argc, t_atom *argv)


and it's called in class_new like this:

 zmq_class = class_new(gensym("zmq"),
   (t_newmethod) zmq_new,
   (t_method) zmq_destroy,
   sizeof(t_zmq),
   CLASS_DEFAULT, A_GIMME, 0);


the entire code is available at:

https://github.com/sansculotte/pd-zmq


thanks a lot,

ub


___
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] Problem with this (involved) abstraction for XY

[Christof Ressi]

WHERE IS THIS CHANGELOG ENTRY TO BE FOUND?


HERE ARE THE RELEASE NOTES, WHICH INCLUDE THE MOST IMPORTANT (BUT NOT 
ALL!) CHANGES: http://msp.ucsd.edu/Pd_documentation/x5.htm#s1



how the hidden but essential donecanvasdialog settings / behaviour has changed.
To be clear: "donecanvasdialog" is an undocumented *private* message. 
(It is sent from the GUI back to the core upon closing the canvas 
property dialog.) The behavior may change anytime and it won't appear in 
a changelog.


If anything, it is better to use the "coords" message instead because it 
is used in Pd patch files and can be considered stable. However, there 
are still pitfalls with this approach, so the only sane way is to use a 
proper public message as proposed in 
https://github.com/pure-data/pure-data/pull/627.



In all case, I hope this unexpected behaviour report is somewhat helpful.
Yes, it might be still interesting to know what has changed exactly 
because there might be a regression. Can you come up with a minimal 
reproducing example and open an issue on GitHub? Thanks!


Christof

On 30.08.2023 11:23, Pierre Alexandre Tremblay wrote:

Oh the capital shout - I hadn’t seen that in a while :)

There isn’t but I won’t blame anyone, they are a pain to write. So much love 
goes into software maintenance…

I’m spying this:

https://github.com/pure-data/pure-data/commits/master


On 30 Aug 2023, at 10:13, ro...@dds.nl wrote:


Pierre Alexandre Tremblay schreef op 30-08-2023 9:27:

Dear Miller and Christof
I’m sorry to be the cause of pain - I will amend the patch now but
what is strange in this one is that recoding it actually changes its
behaviour.
In all cases, I wish I had seen the changelog entry that would tell me
how the hidden but essential donecanvasdialog settings / behaviour has
changed. In all case, I hope this unexpected behaviour report is
somewhat helpful.


WHERE IS THIS CHANGELOG ENTRY TO BE FOUND?

ROLF



I know my desire to stay vanilla complicates things too, but again, so
many combinations of hardware and oses I think might justify my
self-inflicted pain
p

On 29 Aug 2023, at 23:36, Christof Ressi  wrote:
Sigh.
@Miller Can we please finally get https://github.com/pure-data/pure-data/pull/627? This 
PR has been sitting around for more than 4 years now. In the meantime, people kept 
abusing the private "donecanvasdialog" message in place of a better and 
officially supported alternative, and they will continue to do so...
Christof
On 30.08.2023 00:14, Pierre Alexandre Tremblay wrote:

Ok a lot more investigations later, I have isolated the change of behaviour.
donecanvasdialog 1 -1 0 0 0 0 0 0 0 0 0
Which was used to reset the patcher’s sub patchers at the top left is 
corrupting the ability for a struct to broadcast its click through a graph. 
Now, can anyone on the Pd dev confirm this?
How to reproduce:

https://forum.pdpatchrepo.info/topic/10854/xy-abstraction-to-get-mouse-click-and-drag-coordinates-vanilla

In pd 0.53.2 it works
In pd 0.54.0 it doesn’t receive the click from the #0-rectangle (so it draws 
and emits nothing)
To fix it, remove top left the donecanvasdialog elements (2 of them)
Then reinstantiate the 3 pd Subpatches on the right
(Or you can just try the one I attach)
It is not fixed completely yet but the click gets through now. I really wonder 
what has changed there…
Any pointer (pun intended) welcome
p
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

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

___
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




___
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] Problem with this (involved) abstraction for XY

[Christof Ressi]

Sigh.

@Miller Can we please finally get 
https://github.com/pure-data/pure-data/pull/627? This PR has been 
sitting around for more than 4 years now. In the meantime, people kept 
abusing the private "donecanvasdialog" message in place of a better and 
officially supported alternative, and they will continue to do so...


Christof

On 30.08.2023 00:14, Pierre Alexandre Tremblay wrote:
Ok a lot more investigations later, I have isolated the change of 
behaviour.


donecanvasdialog 1 -1 0 0 0 0 0 0 0 0 0

Which was used to reset the patcher’s sub patchers at the top left is 
corrupting the ability for a struct to broadcast its click through a 
graph. Now, can anyone on the Pd dev confirm this?


How to reproduce:


https://forum.pdpatchrepo.info/topic/10854/xy-abstraction-to-get-mouse-click-and-drag-coordinates-vanilla


In pd 0.53.2 it works

In pd 0.54.0 it doesn’t receive the click from the #0-rectangle (so it 
draws and emits nothing)


To fix it, remove top left the donecanvasdialog elements (2 of them)

Then reinstantiate the 3 pd Subpatches on the right

(Or you can just try the one I attach)

It is not fixed completely yet but the click gets through now. I 
really wonder what has changed there…


Any pointer (pun intended) welcome

p


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




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

Re: [PD] Calling for Pd Windows installer tests.

[Christof Ressi]

Hi Joseph,


3. Pd 0.54.0 without installation, but its 'pd.dll' replaced with the one from 
0.53.2, with 'pd.com' ran directly from 
H:\JOE-W10\Donwloads\pd-0.54-0-modified\bin.
 NOW, it's launching Okay.


on Windows, pd.dll actually contains all the code and pd.exe/pd.com are 
just tiny shims, so your result is not too surprising.


Christof

On 08.08.2023 19:43, Linux ROUEN wrote:

Hello Lucarda,
Thanks for your suggestions. I will test them later on.

But I think we are not searching in the right direction, at least for my PC 
setup.
So I have made further investigations.

I think the culprit on my PC could be the new 'pd.dll' file introduced in Pd 
v.0.54.0.
See the attached zip file containing 3 screen captures highlighting what I'm 
saying:
1. Pd 0.53.2 without installation with 'pd.com' ran directly from 
H:\JOE-W10\Donwloads\pd-0.53-2\bin.
 It's launching Okay.
2. Pd 0.54.0 without installation with 'pd.com' ran directly from 
H:\JOE-W10\Donwloads\pd-0.54-0\bin.
 It's NOT launching at all, just 1 or 2 seconds but nothing on the screen, 
as during all my previous tests.
3. Pd 0.54.0 without installation, but its 'pd.dll' replaced with the one from 
0.53.2, with 'pd.com' ran directly from 
H:\JOE-W10\Donwloads\pd-0.54-0-modified\bin.
 NOW, it's launching Okay.

What do you think about that?
Best, Joseph

-Message d'origine-
De : Pd-list [mailto:pd-list-boun...@lists.iem.at] De la part de Lucas 
Cordiviola
Envoyé : mardi 8 août 2023 14:44
À : pd-list@lists.iem.at
Objet : Re: [PD] Calling for Pd Windows installer tests.

Hi Joseph,

I'm following your case and it's the cause for having a "safer"
installer for good.

In your case we know that pd.exe or pd.com (these are the ones we filter
via tasklist.exe) refuses to open because is blacklisted by the OS so
detection is not working as expected (for your case, of course).


Is it safe in my case to run your 'Pd-0.54-x.windows-installer.exe' to
see if I can get Pd 0.54.0 finally working on my PC ?

You could try it but I expect it won't work because all files, are taken
from Miller's builds and pd.exe, pd.com and pd.dll are the exact same
ones you got blacklisted.

But if you desperately need 0.54-0 you can use the installer new tool
and do this pseudo install:

IIRC you could run the GDB-Pd[*] app you got from
  https://nc.nubegris.com.ar/index.php/s/eKrTbHE4iyqAgAg
- uncompress the folder somewhere in your machine
- run the test installer
- get into: "Repair Pd(64) defaults to open .pd files and exit"
  - select the main folder of your extracted GDB-Pd[*]
- voilà: now .pd files opens with that Pd which is rather the
same you get with the app installed. Note that you don't have any start
menu, desktop short-cut, and other stuff so to start the app you only
need to double-click on any .pd file. (and yes, with this tool all
subsequent double-clicks on .pd files opens in the same Pd instance)

[*] this app contains a 32bit tcl/tk. AFAICT the only thing that does
not work is the dnd-plugin.

Lucarda
--
Mensaje telepatico asistido por maquinas.
= = = = = = = = = =
On 08/08/2023 08:41, Linux ROUEN wrote:

Hello Lucarda,

My PC is running under Windows 10 Pro 64-bit 22H2 (build 19045.3208), and yes 
it has tasklist.exe v.10.0.19041.1. as of 2019/07/12.
Unfortunately I still can't run Pd Vanilla 0.54.0 since I tried to update it 
about one month ago. See my previous emails on this subject.

* All the following tests are done with my Avast antivirus totally disabled.

1. While Pd is running, run the installer 'Pd-0.54-x.windows-installer.exe'
- Trying to run Pd but nothing on the screen, only Wish Application is running 
in the background.
- Now running Pd-0.54-x.windows-installer.exe, at the 4th window there are 3 
choices:
. Continue (normal installation)
. Clear Pd preferences and exit
. Repair Pd(64) defaults to open .pd files and exit
I choose Continue
- On the 5th screen I get:
. Run the uninstaller (recommended)
. Install as an alternate app
. Continue
I choose Cancel
I reboot my PC under Windows.

2. Pd is not running, run the installer 'Pd-0.54-x.windows-installer.exe'
- I checked than neither Wisk nor Pd are running, which is the case.
- Now running Pd-0.54-x.windows-installer.exe at the 4th window there are 3 
choices (same as in above 1.):
. Continue (normal installation)
. Clear Pd preferences and exit
. Repair Pd(64) defaults to open .pd files and exit
I choose Continue
- On the 5th screen I get (same as in above 1.):
. Run the uninstaller (recommended)
. Install as an alternate app
. Continue
I choose Cancel

QUESTION:
Is it safe in my case to run your 'Pd-0.54-x.windows-installer.exe' to see if I 
can get Pd 0.54.0 finally working on my PC ?

Thanks. Best,
Joseph Gastelais

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

Re: [PD] version compile-time checks, was: Building ELSE for Pd Vanilla (here RPi OS 11 32-bit)

[Christof Ressi]

Actually, I think we could streamline this process with a new API 
function: https://github.com/pure-data/pure-data/issues/2075


On 04.08.2023 23:16, Christof Ressi wrote:



To avoid bleeding-edge red, is the following not possible with externals?
This would work in a way that you could compile ELSE for older Pd 
versions. But then you would essentially need to ship two different 
versions: one for Pd 0.54> and another one for Pd 0.54<=.


Ideally, there should be one version that works for both older and 
newer Pd versions. A simple runtime check is not enough because 
multichannel objects need to call a new API function, 
namelysignal_setmultiout(). Any external that calls this function 
would refuse to load with older Pd versions that do not have this symbol.


Now, what you can do is try to load signal_setmultiout() explicitly 
with dlsym resp. GetProcAddress:


typedef void (*signal_setmultiout_fn)(t_signal **, int); 
signal_setmultiout_fn my_signal_setmultiout; // in setup function: 
#ifdef _WIN32 my_signal_setmultiout = 
(signal_setmultiout_fn)GetProcAddress(GetModuleHandle(NULL), 
"signal_setmultiout"); #else my_signal_setmultiout =(signal_setmultiout_fn)dlsym(dlopen(NULL, RTLD_NOW), 
"signal_setmultiout"); #endif // in DSP method: if 
(my_signal_setmultiout) // Pd has multichannel support ... else // no 
multichannel support ...


That's what I am planning to do for vstplugin~ and aoo.

Christof

On 04.08.2023 20:31, Dan Wilcox wrote:

To avoid bleeding-edge red, is the following not possible with externals?

#ifdef PD_MAJOR_VERSION >= 0 and PD_MINOR_VERSION >= 54
// multichannel code
#else
// non-multichannel code
#endif

Depending upon the code layout, you could also probably use some 
macros for lots of redundant stuff.



On Aug 4, 2023, at 8:18 AM, pd-list-requ...@lists.iem.at wrote:

Message: 3
Date: Fri, 4 Aug 2023 03:12:27 -0300
From: Alexandre Torres Porres 
To: Pd-List 
Subject: Re: [PD] Building ELSE for Pd Vanilla (here RPi OS 11 32-bit)
Message-ID:

Content-Type: text/plain; charset="utf-8"

Em qui., 3 de ago. de 2023 ?s 16:46, IOhannes m zm?lnig 


escreveu:


Personally I think this is a bug in ELSE, and would file a bug that it
ought to be buildable against older versions of Pd (even if that means
that some functionality is missing).



I'm creating new objects for multichannel fun and adding multichannel
awareness to old objects, right now there are over 50 signal objects 
that

are multichannel aware (and counting).

Without 0.54 you'll just have many errors trying to deal with
CLASSMULTICHANNEL

So yup, 0.54 is needed. Sorry I'm always on the bleeding edge



Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com>
robotcowboy.com <http://robotcowboy.com>




___
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___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] version compile-time checks, was: Building ELSE for Pd Vanilla (here RPi OS 11 32-bit)

[Christof Ressi]

To avoid bleeding-edge red, is the following not possible with externals?
This would work in a way that you could compile ELSE for older Pd 
versions. But then you would essentially need to ship two different 
versions: one for Pd 0.54> and another one for Pd 0.54<=.


Ideally, there should be one version that works for both older and newer 
Pd versions. A simple runtime check is not enough because multichannel 
objects need to call a new API function, namelysignal_setmultiout(). Any 
external that calls this function would refuse to load with older Pd 
versions that do not have this symbol.


Now, what you can do is try to load signal_setmultiout() explicitly with 
dlsym resp. GetProcAddress:


typedef void (*signal_setmultiout_fn)(t_signal **, int); 
signal_setmultiout_fn my_signal_setmultiout; // in setup function: 
#ifdef _WIN32 my_signal_setmultiout = 
(signal_setmultiout_fn)GetProcAddress(GetModuleHandle(NULL), 
"signal_setmultiout"); #else my_signal_setmultiout =(signal_setmultiout_fn)dlsym(dlopen(NULL, RTLD_NOW), 
"signal_setmultiout"); #endif // in DSP method: if 
(my_signal_setmultiout) // Pd has multichannel support ... else // no 
multichannel support ...


That's what I am planning to do for vstplugin~ and aoo.

Christof

On 04.08.2023 20:31, Dan Wilcox wrote:

To avoid bleeding-edge red, is the following not possible with externals?

#ifdef PD_MAJOR_VERSION >= 0 and PD_MINOR_VERSION >= 54
// multichannel code
#else
// non-multichannel code
#endif

Depending upon the code layout, you could also probably use some 
macros for lots of redundant stuff.



On Aug 4, 2023, at 8:18 AM, pd-list-requ...@lists.iem.at wrote:

Message: 3
Date: Fri, 4 Aug 2023 03:12:27 -0300
From: Alexandre Torres Porres 
To: Pd-List 
Subject: Re: [PD] Building ELSE for Pd Vanilla (here RPi OS 11 32-bit)
Message-ID:

Content-Type: text/plain; charset="utf-8"

Em qui., 3 de ago. de 2023 ?s 16:46, IOhannes m zm?lnig 
escreveu:


Personally I think this is a bug in ELSE, and would file a bug that it
ought to be buildable against older versions of Pd (even if that means
that some functionality is missing).



I'm creating new objects for multichannel fun and adding multichannel
awareness to old objects, right now there are over 50 signal objects that
are multichannel aware (and counting).

Without 0.54 you'll just have many errors trying to deal with
CLASSMULTICHANNEL

So yup, 0.54 is needed. Sorry I'm always on the bleeding edge



Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 




___
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] Fwd: HELP: Pure Data Vanilla v.0.54-0 under Windows 10 22H2 64-bit is not running!

[Christof Ressi]

Hi,
At over 70 years old I'm always ready for learning new technics and 
methods, as long as I'm understanding what I'm doing. 

Big respect! I hope I will be the same at your age :)
- Debugger back-trace 
(https://nc.nubegris.com.ar/index.php/s/JwEjrPDEyP53oL7)
The described steps seem to be for Arch Linux or fork distributions 
and not for Windows?

Msys2 uses pacman as their package manager.
But, for example, its Tcl/Tk and Wish files versions are '85' when in 
the portable version of Pd 0.54.0 they are in '86' version? So at 
least for them we will not compare apples with apples!


I don't think that the GUI plays any part in this, as you got the same 
problems with "pd.com -nogui"


Christof





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

Re: [PD] Fwd: HELP: Pure Data Vanilla v.0.54-0 under Windows 10 22H2 64-bit is not running!

[Christof Ressi]

If I remember well, Lucas has suggested this could be linked to the 
new 64-bit windows build using the lower-latency WASAPI audio system 
in place of the older MMIO.
WASAPI has been introduced in Windows Vista, so I can't imagine how it 
would be a problem on a Windows 10 machine. Also, "pd.com -noprefs 
-noaudio" failed although it wouldn't execute any audio backend code.


Again, the only real way to solve this mystery would be to run Pd in a 
debugger. If are interested to dig deeper, you would need to install 
Msys2 (https://www.msys2.org/), then I could send you a Pd with debug 
symbols.


Christof

On 11.07.2023 03:30, Linux ROUEN wrote:


Hello List,

So few days later and after a lot of tests and support from several 
people, thanks to all of them, this is my current and temporary 
conclusion.


Pd Vanilla 0.54.0 is not compatible with my HP laptop DV8-1190ef (14 
years old with CPU i720Q 1st Gen) and its configuration running under 
Windows 10 22H2 64-bit when Pd Vanilla 0.53.2 is fully functional as 
well as the latest Purr Data 2.19.3.


After having made a new summer in-depth cleaning of my PC, I retest 
the portable versions of Pd Vanilla (see here attached 2 screen captures).


- Pd 0.53.2 = fully functional, but

- Pd 0.54.0 = still not functional at all.

As reported in my previous emails (CrashReport), it seems there is an 
issue with the Windows module “ntdll.dll” (announced as “falling 
module”) or at least the communication between Pd Vanilla 0.54.0 and 
this module.


If I remember well, Lucas has suggested this could be linked to the 
new 64-bit windows build using the lower-latency WASAPI audio system 
in place of the older MMIO.


Now I will wait for the next Pd 0.54.1 for making new tests.

I’m really pleased for those who are able to run Pd 0.54.0 on their 
Windows 10 machines.


Best,

Joseph Gastelais

*De :*Linux ROUEN [mailto:linux.ro...@free.fr]
*Envoyé :* samedi 8 juillet 2023 03:34
*À :* 'Pd-list'
*Objet :* HELP: Pure Data Vanilla v.0.54-0 under Windows 10 22H2 
64-bit is not running!


Hello Pd List,

Under Windows 10 22H2 64-bit, the previous 3 versions 0.53.0, 0.53.1 
and 0.53.2 of Pure Data Vanilla were working okay, but not the latest 
0.54.0 version!


I tried today to update to it using the 
‘pd-0.54-0.windows-installer.exe’ file from Miller’s site but after 
the installation trying to launch it nothing happens.


Installation procedure (with antivirus disabled):

- Uninstall Pd 0.53.2: okay

- Install ‘pd-0.54-0.windows-installer.exe’: everything went well

- Launch Pd 0.54.0: nothing happens!

- Uninstall Pd 0.54.0: okay

- Reinstall ‘pd-0.53-2.windows-installer.exe’: but lot of errors which 
was not the case previously!


- Launch Pd 0.53.2: it’s opening?!

See the attached zip file for the error messages.

- Uninstall Pd 0.53.2: okay

- Reinstall ‘pd-0.54-0.windows-installer.exe’: but now a lot of errors 
like with 0.53.2 reinstallation!


- Launch Pd 0.54.0: still nothing happens!!

See the attached zip file for the error messages.

See also the attached Pd Bin & Font zip file for the folders content.

Any idea what is going wrong with Pd 0.54.0 installation and now also 
with Pd 0.53.2 reinstallation?


Everything seems to be broken!

Thanks,

Joseph Gastelais


___
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] HELP: Pure Data Vanilla v.0.54-0 under Windows 10 22H2 64-bit is not running!

[Christof Ressi]

So within a CMD terminal the following commands
- pd.com
- pd.com -stderr -verbose
- pd.com -nogui
- pd.com -noprefs
give the same "no result" for both the installed and the portable versions
of Pd 0.54.0.


Ok, thanks for testing. So it has nothing to do with the registry or 
with the gui preferences...


Now, can you also try "pd.com -noaudio"? And also "pd.com -stderr 
-verbose -noprefs -nogui -noaudio"?



==> Sig[3].Name=Nom du module défaillant = Name of the failing module
==> Sig[3].Value=ntdll.dll


Ah, right I missed that. Unfortunately, the crash report is very vague. 
To get the actual reason for the crash you would need to run Pd in a 
debugger...


Christof




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

Re: [PD] HELP: Pure Data Vanilla v.0.54-0 under Windows 10 22H2 64-bit is not running!

[Christof Ressi]

Just to add another data point: I could install Pd 0.54 over Pd 0.53-2 
without any problems.


Christof




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

Re: [PD] HELP: Pure Data Vanilla v.0.54-0 under Windows 10 22H2 64-bit is not running!

[Christof Ressi]

Hi,

After further searching on my PC, I was able to find the Windows AppCrash
report (in the hidden C:\ProgramData\Microsoft\Windows\WER\ReportArchive)
for this test which is here attached: "AppCrash_pd.com_Report1.wer" file
(text format).
As we can see on lines 29-32 the culprit (direct or indirect) seems to be
the "ntdll.dll" module.


this is just the list of loaded modules. It doesn't say anything about 
where the crash happens.


Please try to run Pd from the command line with the following flags and 
tell the results:


1. pd.com -noprefs

2. pd.com -nogui

Cheers,

Christof





___
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-0 test 1 released

[Christof Ressi]

OTOH, if "preferences" are left around from 0.53 to 0.54 that could 
potentially cause trouble if something that was appropriate for 0.53 
somehow crashes 0.54
"Wrong" preferences should never crash Pd in the first place... It would 
be really great if Oliver would somehow manage to recreate the settings 
that led to the crash.


Christof

On 22.06.2023 21:17, Miller Puckette wrote:


On 6/22/23 11:50, Lucas Cordiviola wrote:

On 22/06/2023 15:41, oliver wrote:

It seems to not overwrite the old installation completely,
or so it seems to me. 



I think you runned the *new* installer whithout a prior uninstall 
(and you overwrited files).


The new installer will (in the future) warn you and ask you to 
uninstall first. but this warning is not happening if you have Pd < 
0.54 installed.


I got a different ride... installing 0.54 on top of 0.53 the installer 
did give me the option to erase the old one.  I tried it both with and 
without the "uninstall" option and had no trouble either way.  Since 
the new one will overwrite any files it needs, it shouldn't be 
strictly necessary to uninstall 0.53 files that got renamed or removed 
in 0.54 - they should just hang around but not do anything.  OTOH, if 
"preferences" are left around from 0.53 to 0.54 that could potentially 
cause trouble if something that was appropriate for 0.53 somehow 
crashes 0.54, which is what I think Oliver saw.  If that's true, the 
only way to recreate Oliver's crash would be to re-establish the 
preferences he had in 0.53 and then install 0.54 on top of it without 
"uninstalling".


Or perhaps something totally different from that was going wrong...?

cheers

Miller




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




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

Re: [PD] [PD-announce] Pd 0.54-0 test 1 released

[Christof Ressi]

anyhow, this is not something i think worth spending my time on. 

Agreed :)



___
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-0 test 1 released

[Christof Ressi]

To make things more fun, the TclTk included in the mac/stuff/ (which is the 
version that most people will get when building the app themselves) is one that 
crashed for me.
Side note: we should really update the prototypes for macOS and Windows 
at one point. msw/pdprototype.tgz still contains Tcl/Tk 8.5...


Christof

On 21.06.2023 18:57, IOhannes m zmölnig wrote:

Am 21. Juni 2023 12:42:25 MESZ schrieb Dan Wilcox :

I think min Tk version for macOS and tabs should be 8.6.10 or 11. We may 
possible also need an os version check, hopefully not.

My code explicitly checks for TclTk<<8.6.12 (and >= 8.6), so I think I tested 
and it crashed with 8.6.11.


To make things more fun, the TclTk included in the mac/stuff/ (which is the 
version that most people will get when building the app themselves) is one that 
crashed for me.
Luckily, the version that is used for the app distributed by miller (and built 
on the iem premises), is a newer one, that is known to work.
So most "users" should get a version that is good.


The main thing to avoid is if anyone runs an older Tk 8.6, especially the buggy 
one that used to be included with macOS itself.

And please do not forget that we are still trying to support macOS versions 
(and possibly OSX versions) that are rather old and cannot use a newer TclTk.
Or there is some signing/notarization issue (eg Apple refusing to notarize 
binaries that also contain 32bit intel code).
The point is: it is not obviously simple to "just switch to the latest and 
greatest" if we want to keep our obsolescence doctrine.


mfg.sfg.jfd
IOhannes


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




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

Re: [PD] [PD-announce] Pd 0.54-0 test 1 released

[Christof Ressi]

Also, I just wiped my Pd preferences on macOS and started the new app. 
The preferences are indeed tabbed by default, but strangely "Tabbed 
preferences" is not ticked (unlike on Windows).


Except for that little quirk everything seems to work as intended. Sorry 
again for the confusion!


Christof

On 21.06.2023 21:14, Christof Ressi wrote:
maybe it's after all some weird configuration on your side? 
A... yes. I just started with -noprefs and now Pd opens with 
tabbed preferences enabled by default. Sorry for the noise!


Anyway, nice work! :)

On 21.06.2023 21:08, IOhannes m zmölnig wrote:

On 6/21/23 20:18, Christof Ressi wrote:


Anyway, my take-away is that a simple runtime check for Tcl/Tk 
8.x+ could be a viable solution.
This pretty much exactly describes what is happening in the current 
master branch.



I'm slightly baffled that the default is to*not* use tabs, because 
iirc it should use them.
But then, the choice whether you get tabs or not can be overridden 
via GUI preferences, so maybe I just forgot to reset then at some 
point...


Note that Windows and Linux currently also use non-tabbed 
preferences by default. From your mail I gather that this is just an 
oversight?



it is definitely not intended behaviour.

however, i just tested current 'master' (on Debian/Sid with 
Tcl/Tk-8.6.13):
after wiping my GUI preferences, and starting Pd, I definitely get 
tabbed behaviour.


maybe it's after all some weird configuration on your side?
or do others experience this as well?

gmdasr
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




___
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-0 test 1 released

[Christof Ressi]

maybe it's after all some weird configuration on your side? 
A... yes. I just started with -noprefs and now Pd opens with tabbed 
preferences enabled by default. Sorry for the noise!


Anyway, nice work! :)

On 21.06.2023 21:08, IOhannes m zmölnig wrote:

On 6/21/23 20:18, Christof Ressi wrote:


Anyway, my take-away is that a simple runtime check for Tcl/Tk 8.x+ 
could be a viable solution.
This pretty much exactly describes what is happening in the current 
master branch.



I'm slightly baffled that the default is to*not* use tabs, because 
iirc it should use them.
But then, the choice whether you get tabs or not can be overridden 
via GUI preferences, so maybe I just forgot to reset then at some 
point...


Note that Windows and Linux currently also use non-tabbed preferences 
by default. From your mail I gather that this is just an oversight?



it is definitely not intended behaviour.

however, i just tested current 'master' (on Debian/Sid with 
Tcl/Tk-8.6.13):
after wiping my GUI preferences, and starting Pd, I definitely get 
tabbed behaviour.


maybe it's after all some weird configuration on your side?
or do others experience this as well?

gmdasr
IOhannes

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




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

Re: [PD] [PD-announce] Pd 0.54-0 test 1 released

[Christof Ressi]

Anyway, my take-away is that a simple runtime check for Tcl/Tk 8.x+ could be a 
viable solution.

This pretty much exactly describes what is happening in the current master 
branch.


I'm slightly baffled that the default is to*not* use tabs, because iirc it 
should use them.
But then, the choice whether you get tabs or not can be overridden via GUI 
preferences, so maybe I just forgot to reset then at some point...


Note that Windows and Linux currently also use non-tabbed preferences by 
default. From your mail I gather that this is just an oversight?


Christof




___
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-0 test 1 released

[Christof Ressi]

Thanks for clarifying!

Anyway, my take-away is that a simple runtime check for Tcl/Tk 8.x+ 
could be a viable solution.


On 21.06.2023 13:39, Dan Wilcox wrote:

It nominally uses the Tk frameworks in the .app bundle *but* someone could 
always build using a different Tk which could lead to issues. Also, people 
trying to run Pd on the command line from the build folder without making an 
app bundle end up using the system Tk. This works ok for testing basic things 
but is bad news for normal usage.

enohp ym morf tnes
---
Dan Wilcox
danomatika.com
robotcowboy.com



On Jun 21, 2023, at 12:55 PM, Christof Ressi  wrote:

Thanks for chiming in!


Tabs should default unless a min version check on the platform fails.

That's what I figured.


especially the buggy one that used to be included with macOS itself.

Wouldn't the Pd app prefer the bundled Tk version? (I don't know these things 
work on macOS.)

Christof


On 21.06.2023 12:42, Dan Wilcox wrote:
I think min Tk version for macOS and tabs should be 8.6.10 or 11. We may 
possible also need an os version check, hopefully not.

The main thing to avoid is if anyone runs an older Tk 8.6, especially the buggy 
one that used to be included with macOS itself.

enohp ym morf tnes
---
Dan Wilcox
danomatika.com
robotcowboy.com



On Jun 21, 2023, at 12:38 PM, Dan Wilcox  wrote:

I agree. Tabs should default unless a min version check on the platform fails. 
The original suggestion for making the option to still host dialogs in windows 
was mine, I believe, large for this reason, ie. building for OS X 10.6 and Tk 
8.4 which doesn’t have the tabs widget.

enohp ym morf tnes
---
Dan Wilcox
danomatika.com
robotcowboy.com



On Jun 21, 2023, at 12:07 PM, Christof Ressi  wrote:



basically, because some TclTk versions on macOS would just crash when using 
tabs.

Wow, Tk never ceases to amaze me...

Does this also happen with the Tcl/Tk version that is included in the 
"official" macOS app bundle?

Could we do a runtime check for specific Tcl/Tk versions that are known to work?

I think the tabbed preferences are just so nice and it would be shame to hide 
them from the user by default...

(At the very least, we should use tabbed preference by default on Windows and 
Linux :-)

Christof


On 21.06.2023 00:07, IOhannes m zmölnig wrote:

On 6/20/23 20:35, Christof Ressi wrote:
First off: thanks Miller for this historic release :-)

I just discovered the new tabbed preferences and I really like them! Thanks 
IOhannes!

Question: why do we have both tabbed and non-tabbed preferences? This feels 
very weird to me. I don't see any advantages in the non-tabbed preferences... 
(I find them rather grotesque).

basically, because some TclTk versions on macOS would just crash when using 
tabs.
so I needed a fallback for this case anyhow (that, albeit grotesque, is still 
somewhat useable)



gmds
IOhannes

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




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

Re: [PD] [PD-announce] Pd 0.54-0 test 1 released : [plot] visibility

[Christof Ressi]

Thanks for the report! I can also confirm this for other drawing 
instructions. I have opened a ticket on GitHub: 
https://github.com/pure-data/pure-data/issues/2007


On 21.06.2023 13:01, ro...@dds.nl wrote:


Windows 11

create [plot], open plot-help, open plot-template.

the visibility examples only have visible effect when changing the 
size of the plot-data window!



(in my own, more complicated, use of graphs i have to move the cursor 
in and out of the graph-'window').



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] [PD-announce] Pd 0.54-0 test 1 released

[Christof Ressi]

The "Save All Settings" buttons are redundant in the tabbed preferences 
because hitting "Apply" or "Ok" already does that.


On 20.06.2023 22:50, Lucas Cordiviola wrote:


We are missing a "Save All Settings" button on the tabbed prefs for 
"Audio" and "MIDI" tabs.




--

Mensaje telepatico asistido por maquinas.
On 20/06/2023 15:53, Christof Ressi wrote:


Side note: on macOS, "Pd->Settings..." shows tabbed preferences by 
default, but "Pd->Preferences->Edit Preferences..." is non-tabbed by 
default...


On 20.06.2023 20:35, Christof Ressi wrote:


First off: thanks Miller for this historic release :-)

I just discovered the new tabbed preferences and I really like them! 
Thanks IOhannes!


Question: why do we have both tabbed and non-tabbed preferences? 
This feels very weird to me. I don't see any advantages in the 
non-tabbed preferences... (I find them rather grotesque).


Also, the audio settings in the preference tab now has a dropdown 
list where you can select the audio API:


(I think I have proposed this back then.)

Can we please also use this for the "Media->Audio Settings" dialog, 
so we can get rid of the redundant (and confusing) audio API entries 
in the "Media" menu (see below)?


Cheers,

Christof

On 20.06.2023 05:49, Miller Puckette wrote:

To Pd-announce:

Pd version 0.54-0test1 is available from 
http://msp.ucsd.edu/software.htm

or (source only) via github: https://github.com/pure-data/pure-data

New features include multi-channel signal connections and updated 
windows audio.  The new window version uses an audio subsystem that 
became available in windows 7 (so won't work on Windows XP any more 
but should be fine for windows 7 or newer).  There are many other 
improvements and updates.


cheers

Miller




___
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


___
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


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

Re: [PD] [PD-announce] Pd 0.54-0 test 1 released

[Christof Ressi]

Thanks for chiming in!


Tabs should default unless a min version check on the platform fails.

That's what I figured.


especially the buggy one that used to be included with macOS itself.
Wouldn't the Pd app prefer the bundled Tk version? (I don't know these 
things work on macOS.)


Christof

On 21.06.2023 12:42, Dan Wilcox wrote:

I think min Tk version for macOS and tabs should be 8.6.10 or 11. We may 
possible also need an os version check, hopefully not.

The main thing to avoid is if anyone runs an older Tk 8.6, especially the buggy 
one that used to be included with macOS itself.

enohp ym morf tnes
---
Dan Wilcox
danomatika.com
robotcowboy.com



On Jun 21, 2023, at 12:38 PM, Dan Wilcox  wrote:

I agree. Tabs should default unless a min version check on the platform fails. 
The original suggestion for making the option to still host dialogs in windows 
was mine, I believe, large for this reason, ie. building for OS X 10.6 and Tk 
8.4 which doesn’t have the tabs widget.

enohp ym morf tnes
---
Dan Wilcox
danomatika.com
robotcowboy.com



On Jun 21, 2023, at 12:07 PM, Christof Ressi  wrote:



basically, because some TclTk versions on macOS would just crash when using 
tabs.

Wow, Tk never ceases to amaze me...

Does this also happen with the Tcl/Tk version that is included in the 
"official" macOS app bundle?

Could we do a runtime check for specific Tcl/Tk versions that are known to work?

I think the tabbed preferences are just so nice and it would be shame to hide 
them from the user by default...

(At the very least, we should use tabbed preference by default on Windows and 
Linux :-)

Christof


On 21.06.2023 00:07, IOhannes m zmölnig wrote:

On 6/20/23 20:35, Christof Ressi wrote:
First off: thanks Miller for this historic release :-)

I just discovered the new tabbed preferences and I really like them! Thanks 
IOhannes!

Question: why do we have both tabbed and non-tabbed preferences? This feels 
very weird to me. I don't see any advantages in the non-tabbed preferences... 
(I find them rather grotesque).

basically, because some TclTk versions on macOS would just crash when using 
tabs.
so I needed a fallback for this case anyhow (that, albeit grotesque, is still 
somewhat useable)



gmds
IOhannes

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




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

Re: [PD] [PD-announce] Pd 0.54-0 test 1 released

[Christof Ressi]

basically, because some TclTk versions on macOS would just crash when 
using tabs. 

Wow, Tk never ceases to amaze me...

Does this also happen with the Tcl/Tk version that is included in the 
"official" macOS app bundle?


Could we do a runtime check for specific Tcl/Tk versions that are known 
to work?


I think the tabbed preferences are just so nice and it would be shame to 
hide them from the user by default...


(At the very least, we should use tabbed preference by default on 
Windows and Linux :-)


Christof

On 21.06.2023 00:07, IOhannes m zmölnig wrote:

On 6/20/23 20:35, Christof Ressi wrote:

First off: thanks Miller for this historic release :-)

I just discovered the new tabbed preferences and I really like them! 
Thanks IOhannes!


Question: why do we have both tabbed and non-tabbed preferences? This 
feels very weird to me. I don't see any advantages in the non-tabbed 
preferences... (I find them rather grotesque).


basically, because some TclTk versions on macOS would just crash when 
using tabs.
so I needed a fallback for this case anyhow (that, albeit grotesque, 
is still somewhat useable)




gmds
IOhannes

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




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

Re: [PD] [PD-announce] Pd 0.54-0 test 1 released

[Christof Ressi]

and that the other fft objects can't handle it yet
actually, [rifft~] *can* handle multi-channel signals, it just missed 
the CLASS_MULTICHANNEL flag. I just pushed a fix to develop.


[fft~] and [ifft~] still single-channel, but personally I don't care 
because I have never used them :-)


Christof

On 20.06.2023 20:29, Alexandre Torres Porres wrote:
oh, I also see rfft~ takes multichannel signals, but this is not yet 
documented and that the other fft objects can't handle it yet, I 
created this ticket for it in pddp 
https://github.com/pure-data/pddp/issues/153


Em ter., 20 de jun. de 2023 às 14:12, Alexandre Torres Porres 
 escreveu:


So great, can't remember being this excited about a release, thanks!

A few things. Looks like we have the double precision app. At
least deken detects /Darwin-amd64-float64/ and Pd refuses to load
my externals.

By the way, I hope there is time to merge the branch where both
float32/64 live together!

Sigmund~ is still at version 0.7 in the code, but this is a newer
version. And I don't get the version printed anymore when loading
the object as it used to do. Somehow the post doesn't happen.

In the new tabbed preferences we have 'path preferences' /
'startup preferences' / 'audio preferences' / 'midi preferences' /
'misc preferences'  and I think it is redundanct to have
'preferences' al lthe time, wince we are already under the
"preferences" window. We could just have  'path' / 'startup' /
'audio' / 'midi' / 'misc' instead.

I also hope there is time to include at least the 'font weight'
settings in 'misc' as I proposed.

I hope and wish we can also add message methods to change the
multichannel settings of [clone], see
https://github.com/pure-data/pure-data/pull/2004

cheers

Em ter., 20 de jun. de 2023 às 01:47, Miller Puckette
 escreveu:

To Pd-announce:

Pd version 0.54-0test1 is available from
http://msp.ucsd.edu/software.htm
or (source only) via github:
https://github.com/pure-data/pure-data

New features include multi-channel signal connections and updated
windows audio.  The new window version uses an audio subsystem
that
became available in windows 7 (so won't work on Windows XP any
more but
should be fine for windows 7 or newer).  There are many other
improvements and updates.

cheers

Miller




___
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


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

Re: [PD] [PD-announce] Pd 0.54-0 test 1 released

[Christof Ressi]

Side note: on macOS, "Pd->Settings..." shows tabbed preferences by 
default, but "Pd->Preferences->Edit Preferences..." is non-tabbed by 
default...


On 20.06.2023 20:35, Christof Ressi wrote:


First off: thanks Miller for this historic release :-)

I just discovered the new tabbed preferences and I really like them! 
Thanks IOhannes!


Question: why do we have both tabbed and non-tabbed preferences? This 
feels very weird to me. I don't see any advantages in the non-tabbed 
preferences... (I find them rather grotesque).


Also, the audio settings in the preference tab now has a dropdown list 
where you can select the audio API:


(I think I have proposed this back then.)

Can we please also use this for the "Media->Audio Settings" dialog, so 
we can get rid of the redundant (and confusing) audio API entries in 
the "Media" menu (see below)?


Cheers,

Christof

On 20.06.2023 05:49, Miller Puckette wrote:

To Pd-announce:

Pd version 0.54-0test1 is available from 
http://msp.ucsd.edu/software.htm

or (source only) via github: https://github.com/pure-data/pure-data

New features include multi-channel signal connections and updated 
windows audio.  The new window version uses an audio subsystem that 
became available in windows 7 (so won't work on Windows XP any more 
but should be fine for windows 7 or newer). There are many other 
improvements and updates.


cheers

Miller




___
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


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

Re: [PD] [PD-announce] Pd 0.54-0 test 1 released

[Christof Ressi]

First off: thanks Miller for this historic release :-)

I just discovered the new tabbed preferences and I really like them! 
Thanks IOhannes!


Question: why do we have both tabbed and non-tabbed preferences? This 
feels very weird to me. I don't see any advantages in the non-tabbed 
preferences... (I find them rather grotesque).


Also, the audio settings in the preference tab now has a dropdown list 
where you can select the audio API:


(I think I have proposed this back then.)

Can we please also use this for the "Media->Audio Settings" dialog, so 
we can get rid of the redundant (and confusing) audio API entries in the 
"Media" menu (see below)?


Cheers,

Christof

On 20.06.2023 05:49, Miller Puckette wrote:

To Pd-announce:

Pd version 0.54-0test1 is available from http://msp.ucsd.edu/software.htm
or (source only) via github: https://github.com/pure-data/pure-data

New features include multi-channel signal connections and updated 
windows audio.  The new window version uses an audio subsystem that 
became available in windows 7 (so won't work on Windows XP any more 
but should be fine for windows 7 or newer).  There are many other 
improvements and updates.


cheers

Miller




___
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___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Concert invitation - Cologne, May 27

[Christof Ressi]

Apologies for cross-posting!

---

This Saturday, May 27, /project ensemble morph/ will be so brave and 
perform my new piece /Rizumu Gēmu/ in Cologne, together with other 
exiciting pieces.


/Rizumu Gēmu/ is an algorithmic composition for 5 instruments inspired 
by Japanese Arcade-Rhythm-Games. The score is generated in real-time and 
streamed to the player's tablets. A graphical representation of the 
score is projected on a screen, so that the audience can follow and also 
anticipate the music. The piece is built upon a baroque mix of 
SuperCollider, Pure Data, Python and JavaScript – so something for 
everyone :crazy_face:


The concert already starts at 19:00, so there is enough time to hang out 
afterwards! Here's some more info:


https://altes-pfandhaus.de/event/project-ensemble-morph-im-alten-pfandhaus/

Cheers,

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

Re: [PD] [r pd-dsp-started] bangs upon object deletion?

[Christof Ressi]

I am wondering why it outputs a bang when I create an (empty) object

Does it really? Not for me.


and delete it again


Deleting any object causes the DSP graph to be updated. (As a side note, 
I *think* this wouldn't be necessary for non-DSP objects, but maybe I am 
missing something.)



so the object reports all updates to the dsp graph maybe?

Yes! A signal graph update implies that DSP is stopped and (re)started.

Christof

On 15.05.2023 12:33, Peter P. wrote:

Adding to my last email, that it outputs bangs when signal connections
are drawn. So the object reports all updates to the dsp graph maybe?

* Peter P.  [2023-05-15 12:31]:

Hi list,

I am using [r pd-dsp-started] to recalculate parameters. I am wondering
why it outputs a bang when I create an (empty) object, and delete it
again, either with the "Cut" menu item or the backspace key.

Is this intentional and what would be a rationale?

Thanks!
P



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




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

Re: [PD] Number atom box limits overstepped

[Christof Ressi]

it's super-simple to just add a [clip 0 127] (or whatever) before or 
after the slider to achieve the behavior you are looking after. 
The problem is that now you have to make sure that these two ranges 
always stay in sync. (It is easy to accidentally change one while 
keeping the other.)


that would mean, that they cannot be used for "filtering" 
(out-of-bound values). 

It's not only about filtering. The "set" message has the same problem.

I think we should generally follow the principle of least surprise. If a 
numberbox allows to set a lower and upper bound, I guess most users 
would expect that this range is always respected.


But that's just my 22¢ :)

Christof

On 11.05.2023 16:37, IOhannes m zmoelnig wrote:

On 5/11/23 14:30, William Huston wrote:

Joao,

IIRC, some objects in pd-extended, like hsliders,
would always respect the limits whether dialed-in, or
when coming from an input.

When i finally switched to vanilla, I noticed the same thing,
limits were not respected on the inputs, and a lot of my patches broke.

I don't know whether the "sensible" behavior was ever in the
mainline branch, or only in -extended.


for me the "sensible" thing is to keep the GUI-objects as minimal as 
possible.
that would mean, that they cannot be used for "filtering" 
(out-of-bound values).
it's super-simple to just add a [clip 0 127] (or whatever) before or 
after the slider to achieve the behavior you are looking after.
otoh, it is not *so* super-simple to build a patch that prevents a 
user from dragging a numberbox out of bounds, so i understand why this 
functionality is in. (it's of course possible).


otoh, the GUI objects are already full of various cruft (starting with 
the possibility to set lower and upper ranges in sliders, and various 
characteristics... ideally they would just output 0..1 and the user 
can then map that to whatever they need).


but that is just my 2¢ (from a minimalistic POV).

masd
IOhannes

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




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

Re: [PD] Audio latency on linux

[Christof Ressi]

Hi,


I found it: The delay setting in the audio settings is the culprit:
It was set at 25 ms and setting
If you want to reduce latency even more, try to enable "callbacks" in 
the audio settings (or start Pd with the "-callback" option). Generally, 
this is not recommend, unless you really need the lowest possible latency.

I even tried to compile pd with a lower blocksize

To anyone reading: don't try this at home!

Christof

On 10.05.2023 19:04, Orm Finnendahl wrote:

Hi,

  for a project involving controlled and tuned feedback through the
Audio Interface, we need very low latency (~ 9-10 ms roundtrip through
the analog ins/outs) for it to work properly. We did some tests using
OSX and linux based systems with different audio interfaces.

On OSX I can get down to 16 ms with pd (44.1 kHz sr); using Max/MSP we
can get below 10ms with a vector size of 32.

On Linux the lowest I can get with pd is 29.33 ms with 48k samplerate
(this is using alsa; jack is ~34 ms).

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. I don't know if
jack_delay is implemented with additional i/o buffers but even if pd
adds an extra period in both directions that should be well below 30ms
(64 samples are 1.33 ms at 48k). The added 20ms in comparison to
jack_delay appear quite large to me.

I even tried to compile pd with a lower blocksize (I changed
DEFDACBLKSIZE in s_stuff.h and DEFSENDVS in d_global.c and can get
down to a vectorsize of 32 without distortion at the audio interface),
but that doesn't change the i/o latency at all. I didn't yet study the
alsa/jack related code.

Can anyone shed a light on this? It'd be much nicer to use pd for this
than writing a dedicated app doing all the dsp (or using Max/MSP on
OSX :-(

--
Orm





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




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

Re: [PD] pd~ set audio API on linux

[Christof Ressi]

so I solved it by starting pd processes from the shell and communicating 
to/from the main patch using OSC.

Yes, that's how you would typically manage independent Pd instances.

Christof

On 07.05.2023 10:00, Orm Finnendahl wrote:

Hi IOhannes, Christof,

  in my use case the subprocesses don't need to receive/send audio to
the main process and pd~ seems to introduce additional latency so I
solved it by starting pd processes from the shell and communicating
to/from the main patch using OSC.

In any case it's good to know about mediasettings, that seems quite
useful.

--
Orm

Am Samstag, den 06. Mai 2023 um 10:18:22 Uhr (+0200) schrieb IOhannes m 
zmoelnig:

Am 5. Mai 2023 21:57:37 MESZ schrieb Christof Ressi :

[pd~] is designed to pipe audio through the subprocess. The code does not (or rather should not) 
allow the subprocess to use a real audio device. Ideally, we should disable the "audio 
settings" and audio API entries in the "Media" menu for subprocesses, as they don't 
have any meaning in this context.

And just for the record: of course Christof is right (like always), and with my previous 
answer I did not want that "mediasettings" would make things to start working 
magically.
Only if changing the audio backend is possible somehow, then "mediasettings" 
allowed you to do so programmatically and with a well-defined interface.


mfg.sfg.jfd
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




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

Re: [PD] pd~ set audio API on linux

[Christof Ressi]

Hi,


the subprocess outputs "no audio API specified" to its pd window
Can confirm on Windows. It's a spurious error message. I just opened a 
ticket: https://github.com/pure-data/pure-data/issues/1952



It works receiving/sending audio from/to the parent process but in my special 
use case it'd be
even nicer to input/output audio directly to the interface
[pd~] is designed to pipe audio through the subprocess. The code does 
not (or rather should not) allow the subprocess to use a real audio 
device. Ideally, we should disable the "audio settings" and audio API 
entries in the "Media" menu for subprocesses, as they don't have any 
meaning in this context.



which works as soon as I specify the audio API in the media prefs of the 
subprocess.

I highly doubt that this actually works.

Christof

On 05.05.2023 15:54, Orm Finnendahl wrote:

Hi,

  when using pd~ on linux and turning dsp on, the subprocess outputs
"no audio API specified" to its pd window. It works receiving/sending
audio from/to the parent process but in my special use case it'd be
even nicer to input/output audio directly to the interface, which
works as soon as I specify the audio API in the media prefs of the
subprocess.

Is it possible to specify the jack audio API somehow to the subprocess
via message and/or params to pd~ to automate this?

--
Orm



___
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] midi file into [text sequence]?

[Christof Ressi]

You can read the MIDI file with [mrpeach/midifile], output everything in 
a loop and save the MIDI messages in a [text] object. You just need to 
calculate the appropriate time delta between messages.


Christof

On 22.04.2023 07:46, Peter P. wrote:

Hi,

starting to use [text sequence] instead of [qlist] more and more, I am
wondering how difficult it might be to write an external script that
converts .mid file into .txt usable by [textfile sequence]?

Has anyone attempted something similar already? What would be the
easiest language and/or libraries to do this on DebianGNU Linux?

Thanks!
Peter



___
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] Raspberry pi 4 startup problem

[Christof Ressi]

I tried delaying the dsp 1 message on loadbang by 200ms since I read somewhere 
this could be the problem.

Try

[loadbang] --> [del 1000] --> [; pd dsp 0, dsp1(

If the audio device has already been opened (albeit unsuccessfully), you 
might need to turn DSP off first, so that turning DSP on will reopen the 
device.


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

[Christof Ressi]

That's exciting news!

but I hope it shows that there is a tcl-tk-compatible, non-tcl-tk 
future possible for Pd. 

I am very much looking forward to such a future :-)

Christof

On 16.03.2023 22:02, 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

This leverages the refactored communication protocol effort by 
Iohannes in order to obtain a "toolkit-agnostic Core<->GUI 
Communication" 
(https://github.com/pure-data/pure-data/discussions/1695), which 
resulted in https://github.com/pure-data/pure-data/pull/1765 . This is 
part of a broader project outlined in 
https://github.com/pure-data/pure-data/pull/1693 .


Now, this pure-data-web-GUI repo comprises three components:

- pd: is started with -guiport so that it doesn't start its own GUI
- the "shim": a very thin layer of websocket that forwards messages 
to/from Pd and the browser
- the "frontend": the actual HTML5 stuff, written using the svelte 
framework.


For now, you can try it out with docker following the instructions 
included in the repo. The easiest way is to run it with the Pd it 
comes with (which is run inside docker and thus doesn't have 
audio/MIDI I/O capabilities), but you can easily connect it to your 
own Pd server instance (assuming it comes from this branch 
https://github.com/giuliomoro/pure-data-1/). The docker containers are 
used to simplify the development effort, but ultimately this can be 
packaged up in a self-contained app (even for Android, if required), 
or you can have it run embedded (e.g.: on a Bela board) while 
displaying the GUI in a web browser (which is actually our primary goal).


It is by no mean complete or perfect, but I hope it shows that there 
is a tcl-tk-compatible, non-tcl-tk future possible for Pd. As it is, 
it even allows (well, with a lot of effort on the user side, but very 
little effort was put into it from the dev side) to patch on a 
touchscreen.


You may be wondering how this differs from the purr-data web GUI. Good 
question. This is a complete rewrite and it aims to use "stock" Pd as 
a backend server, by means of a communication protocol that has been 
refactored (by Iohannes) such that Pd no longer sends out raw tk 
messages, but rather tcl-compatible commands that are higher level and 
also easier to parse in other languages (the parser here is written in 
js). So right now you can run the same Pd binary (from this branch) 
deciding at runtime if using a tcl GUI or a web GUI. Nifty. The aim is 
eventually to upstream this communication protocol into vanilla, to 
make it easier to swap GUI frontends. Hopefully this can eventually 
help other forks with custom GUIs such as PlugData so that they don't 
have to maintain their own fork of Pd.


Best,
Giulio



___
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] Creating/editing patches on android?

[Christof Ressi]

Do people really want to *edit* Pd patches on a phone or tablet? To me 
this sounds like pure masochism :-D


On 24.02.2023 12:52, Dan Wilcox wrote:

It depends on your workflow. For PdParty, you can stream *all* live sensor 
events over OSC while prototyping in desktop Pd, which is sufficient for my use 
case. Then again, I don’t use my mobile device as an everything computer, so I 
suppose I’m biased.

enohp ym morf tnes
---
Dan Wilcox
danomatika.com
robotcowboy.com



On Feb 24, 2023, at 12:23 PM, Matevz Leskovsek  
wrote:

Dan thanks! Yes your considerations are reasonable but sadly pd has
really lost its "livecoding" angle when Android/iOS devices became so
popular. Smartphones are portable and have so many sensors that
livecoding on android would really make much more sense than coding on
desktop and deploying to smartphone for each change. I hope there will
be some effort to rewrite pd-lib to run in stock android and I am
willing to help (although I am worst programmer ever.. I am kinda good
tester and profiler though). And if it is actually possible to run
pd-lib on rooted android that is interesting but I am somewhat
suspicious. If there is a linux container for androids that would be
easier I guess (but not so RAM friendly). Btw, I've noticed purrdata
js runtime for pd is available but again I think it does not allow
patch creation/editing, only patch running? Btw, pddroidparty webpage
is really nicely organised and clear in its communication -> much
respect! Thanks!


On Fri, Feb 24, 2023 at 12:21 AM Dan Wilcox  wrote:

Howdy Matevz,

I don't believe so, although I must include the caveat tat I do not use 
Android, so perhaps there is something out there I am not aware of.

Running patches via libpd in a mobile app is much easier than creating a live, 
graphical *editor* as with desktop Pd as:

1. the interaction metaphors are different
2. libpd does not have a way to tap into the core pd editing logic (yet)

That being said (written?), it's certainly possible to create something that 
can automate writing a Pd file which can then be loaded by libpd, however, once 
things complicated enough, you basically end up duplicating most of the core 
logic with the detriment that you have to carefully try to keep it up to date 
with whatever version of pd / libpd you are using. In short: it's a lot of 
thankless work that is best *not* done without lots of interest, resources, and 
support.

The closest thing I can think of is rooting the device to install a Linux 
distro so you can run *desktop* Pd, however I don't think this is where your 
question is focused.

As the author of PdParty, which utilizes libpd on iOS, I made a clear decision 
early on to *not* tackle on-device editing, mainly for the reasons mentioned 
above.

On Feb 23, 2023, at 12:00 PM, pd-list-requ...@lists.iem.at wrote:

Message: 2
Date: Thu, 23 Feb 2023 10:44:58 +0100
From: Matevz Leskovsek 
To: pd-list@lists.iem.at
Subject: [PD] Creating/editing patches on android?
Message-ID:

Content-Type: text/plain; charset="UTF-8"

Hi all, as I remember all those PD on Android platforms (mobmuplat,
pddroid) only allowed running patches and not editing those, meaning
that one needed a desktop computer to create and edit patches. Is this
still the case or is it possible now to use Android device for
creating and running pd patches. Thanks!



Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com






___
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] DSP crashing - PD freezes.

[Christof Ressi]

so probably what I describe is here is not directly related.


That's what I tried to say in my last mail. My scheduler fixes - which 
happen to fix the callback issues - are held back for Pd 0.54.


Christof

On 05.02.2023 21:36, Roman Haefeli wrote:

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

___
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] DSP crashing - PD freezes.

[Christof Ressi]

  Are there situations when using
callbacks  (on CoreAudio) bring any benefit?


With "callbacks" enabled, Pd runs directly on the audio thread. 
Generally, this is not really recommended because Pd itself is not 
realtime safe. Many operations block for an indeterminate amount of 
time, e.g. any call to "malloc()", network IO, file system operations, 
etc. The upside is that you can avoid some extra delay (see below).


With Pd's ringbuffer scheduler (= "callbacks" disabled), you can freely 
adjust the delay according to  your needs. (The "delay" parameter 
basically sets the size of the ringbuffer.) The price you pay is some 
extra delay (1x the hardware buffer size). To minimize this extra delay, 
you would set the /hardware buffer size/ as low as possible (e.g. 64 
samples) since the audio callback does nothing but transfer a bunch of 
samples. In this case, the extra latency would be as low as 64 samples, 
so nothing to worry about too much.


(The "callback" option can indeed make a noticable difference when using 
Jack with larger block sizes. Ideally you would just use the smallest 
Jack block size possible, but this might not work well for other Jack 
clients...)


As a side note: up until now, Pd's scheduler thread regularly goes to 
sleep for a fixed duration, so it may wake up a bit too late. If the 
delay setting is too low, this can lead to drop outs. With my 
"scheduler_fix" branch, the scheduler thread waits on a semaphore and is 
notified immediately when audio data is available. In my experience so 
far, this allows for lower "delay" settings than before.


Christof

On 04.02.2023 10:59, Roman Haefeli wrote:

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

  


___
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] DSP crashing - PD freezes.

[Christof Ressi]

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 using it 
on Windows for a few months, but I didn't really test on macOS or with 
Jack so far...


Christof

On 04.02.2023 10:59, Roman Haefeli wrote:

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

  


___
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] DSP crashing - PD freezes.

[Christof Ressi]

FWIW, the callback problem would be fixed with 
https://github.com/pure-data/pure-data/pull/1756


On 04.02.2023 10:04, Dan Wilcox wrote:
Do you have callbacks enabled? If so, disable the checkbox in the 
audio dialog.


enohp ym morf tnes
---
Dan Wilcox
danomatika.com
robotcowboy.com



On Feb 4, 2023, at 9:54 AM, Denis Połeć  wrote:


Hi dan,
 I have tested the build. Unfortunately, I am still experiencing the 
same problem. Nothing works anymore after turning off the DSP.

 I am on ARM - macOS 13.2.

denis.


Am 03.02.2023 um 21:17 schrieb hans w. koch :

hi dan,

thanks for putting this up!
we had one student in a pd class this week, who was running recent 
pd on M1/ventura and it solved her problems!
we didn´t stress test it, but a patch with audio and midi was 
running fine.
patch loading did take a good while though (couldn´t measure if it 
was equally sluggish before)


before your fix, pd would not let her select an audio device or come 
to a crawl on simple operations.


three cheers
hans


Am 02.02.2023 um 21:38 schrieb Dan Wilcox :

Howdy Theron,

can you try this build?

Pd-0.53-1-arm64-pa1970.zip 



It is for arm64 (Apple Silicon) and has Portaudio v19.7.0. I tried 
Miller's build and saw the same "unknown API" print on macOS 11. 
This build seems to work fine for me so, hopefully, it will for you.



On Feb 1, 2023, at 7:20 AM, pd-list-requ...@lists.iem.at wrote:

Message: 2
Date: Tue, 31 Jan 2023 22:12:08 -0800
From: Theron Trowbridge 
To: Miller Puckette 
Cc: "pd-list@lists.iem.at" 
Subject: Re: [PD] DSP crashing - PD freezes.
Message-ID:

Content-Type: text/plain; charset="utf-8"

Mac Mini M1, Ventura 13.1

It works better in some ways - the windows close and things quit 
when I ask
them to. I don't have to force quit, and it doesn't seem to be 
messing up

audio on the computer.

But when I turn on the DSP the output console just spams "unknown 
API" over
and over again, and when I go into audios settings, I don't see my 
usual
devices. The input device list has three options: "input device 
#1", "input
device #2" and "input device #3" and there is no pull-down menu 
for output
device, but only says "(same as input device)..." And I can't get 
it to

make any sound.

When I turn off DSP, it outputs "sys_close_audio: unknown API 4"


-Theron
^



Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
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




___
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] curly braces in Pd

[Christof Ressi]

I agree and think we could just let "{" and "}" be supported as 
regular characters
Just for the sake of clarity: "{" and "}" have never been "forbidden" in 
Pd message, you just cannot /type /them.*)


Christof

*) Actually, you can already type them in [text] windows.

On 13.01.2023 21:03, Alexandre Torres Porres wrote:
So, we've been actually discussing this on github and maybe others can 
participate over there, check 
https://github.com/pure-data/pure-data/issues/505


or... maybe we can use this thread instead... :) seems like github 
discussions are always more limited.


The thing in the way now is wether "{" and "}" should be officially 
incorporated with a new syntax, like nested lists. There are arguments 
against as in the last message by christof here and I agree and think 
we could just let "{" and "}" be supported as regular characters and 
that we can expand the usage of dollar signs for expanding Pd's 
syntax, like ${ and $}


And, also, I'd like to point that there are forks of Pd that actually 
already allow "{" and "}"... I can see why one would disregard this, 
but it's something worth noting. You can already do this in PlugData 
and PurrData/Pd-L2ork, and the patches actually work and are already 
compatible to Pd Vanilla.


I also don't see an expansion of the language syntax coming up very 
soon or easily, so just allowing "{" and "}" could be good to at least 
get this issue out of the way, since it's been bugging people for edge 
cases for ages.


What do you people say?

cheers

Em dom., 8 de jan. de 2023 às 16:15, Christof Ressi 
 escreveu:


> the fact that curlies (that is: a pair of matching characters) have
> been forbidden until now is a unique opportunity.
Well, they have not been forbidden. You can not *type* them (yet),
but
they can appear in text files or in manually assembled symbols. In
fact,
they are properly displayed with [print] or list/symbol atoms, which
suggests that they are already properly escaped when sent to the GUI.
One could argue that someone who only uses libpd might not even be
aware
of this issue.

Curly braces have never been a part of special Pd symbols (semicolon,
colon, dollar), so I'm sceptical that we can just give them some
meaning. It would break lots of existing code that uses symbols with
curly braces. For example, it would completely break the
"purest_json"
library.

However, we could use *escaped* curly braces. The escape sequences
"\{"
and "\}" are not defined, so we might use those for nested lists. I'm
not saying it's pretty, though.

---

Anyway, it's a bit silly that we still can't type curly braces, given
how important they are for many use cases. I mean, I cannot even
type a
JSON string...

Christof




___
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] curly braces in Pd

[Christof Ressi]

the fact that curlies (that is: a pair of matching characters) have 
been forbidden until now is a unique opportunity. 
Well, they have not been forbidden. You can not *type* them (yet), but 
they can appear in text files or in manually assembled symbols. In fact, 
they are properly displayed with [print] or list/symbol atoms, which 
suggests that they are already properly escaped when sent to the GUI. 
One could argue that someone who only uses libpd might not even be aware 
of this issue.


Curly braces have never been a part of special Pd symbols (semicolon, 
colon, dollar), so I'm sceptical that we can just give them some 
meaning. It would break lots of existing code that uses symbols with 
curly braces. For example, it would completely break the "purest_json" 
library.


However, we could use *escaped* curly braces. The escape sequences "\{" 
and "\}" are not defined, so we might use those for nested lists. I'm 
not saying it's pretty, though.


---

Anyway, it's a bit silly that we still can't type curly braces, given 
how important they are for many use cases. I mean, I cannot even type a 
JSON string...


Christof




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

Re: [PD] hidio: can't load library

[Christof Ressi]

Hi,

[hidio] loads just fine here on Windows 10. Either put a [declare -path 
hidio] and then create as [hidio], or create it as [hidio/hidio].


Christof

On 02.12.2022 17:32, Samuel Burt wrote:

Hi, Pd list.

I have a student who was trying to use hidio in Pd in Windows. We have 
64-bit Pd installed and we installed hidio with Deken, but we can't 
get the declare object to load it. When we added it to startup items, 
Pd printed "hidio: can't load library". There was discussion about the 
stability of hidio back in 2019, though, with it in Deken, I'd assume 
that it should be in a usable state. Any updates?


Sam

___
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] OsX : pd 53.0 or pd 52.2 now :)

[Christof Ressi]

See https://github.com/pure-data/pure-data/pull/1672

If you try to open a new stream while a stream is still running (in the 
helper thread), [readsf~] will just go silent.


Christof

On 23.11.2022 21:23, Simon Iten wrote:

hi christof,

i have used readsf~ for an art installation with pd 0.52.2 on a 
raspberry pi 4. (it should run for 18 months now)


i completely missed the serious regression bit, what was it?

i am wondering now, if i have to go and update those PIs..


On Wed, 23 Nov 2022, 17:29 Christof Ressi,  wrote:

> and all what has to be found on the net now, thanks to everyone and
> particularly Miller, is the brand new pd 53.0 :

At the bottom of http://msp.ucsd.edu/software.html click
<http://msp.ucsd.edu/software.html click> click on "directory
listing of
all downloadable files" and it will lead you to
http://msp.ucsd.edu/Software/

BTW, be careful with 0.52-2 because there is a serious regression
in the
[readsf~] object (which has been fixed in 0.53)

Christof




___
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] OsX : pd 53.0 or pd 52.2 now :)

[Christof Ressi]

and all what has to be found on the net now, thanks to everyone and 
particularly Miller, is the brand new pd 53.0 : 


At the bottom of http://msp.ucsd.edu/software.html click 
 click on "directory listing of 
all downloadable files" and it will lead you to 
http://msp.ucsd.edu/Software/


BTW, be careful with 0.52-2 because there is a serious regression in the 
[readsf~] object (which has been fixed in 0.53)


Christof




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

Re: [PD] midi/latency

[Christof Ressi]

Hi Michael,

first off: if you want to start a new thread on the mailing list, don't 
answer to an existing thread and change the subject. Instead, write a 
new mail to pd-list@lists.iem.at. Otherwise your message will be 
associated with the thread you're replying to.


---

I can second everything Oliver has said. I also have the suspicion that 
you have been using the (legacy) MMIO backend. Always use an ASIO driver 
for any kind of low latency stuff! Typically you would use the driver 
provided by the device manufacturer. In some rare cases, ASIO4ALL might 
work better than the official driver, but IMO that would be a red flag.


Here's how you use Pd with an ASIO driver: Pd menu -> "Media" -> "ASIO 
(via portaudio)". In the audio settings dialog, make sure that you 
actually select the correct ASIO driver as input/output devices!


To give you another data point: I'm on Windows 10 and I typically use a 
blocksize of 64 samples and 8-12 ms delay, depending on the patch.


If the Gigaport HD+ does not work at low latencies even with an ASIO 
driver, do yourself a favor and get a better interface. For a low budget 
solution, I can recommend the Behringer UMC series (except for UMC22). 
They are very affordable and reliably work at low latencies. I you have 
a bit more money in your pocket, get something like a Focusrite 
Scarlett. If you want to go pro, have a look at the various RME interfaces.


Cheers,

Christof

On 27.10.2022 14:21, oliver wrote:

michael strohmann wrote:

HI,
what’s your strategies to reduce midi latency ?

in an installation setting i’m triggering samples from an e-drum 
(roland pad, millenium midi module) and the latency a get with the 
settigs below is 114 ms between trigger and sound.


delay(msec): 50 ms
Block Size: 256

if i go any lower i get “resyncing audio” filling up the pd-window 
and occasional glitches up to a frozen pd…


occasionaly after a restart the latency is even closer to 250ms.

i am running this on a fairly decent gamer pc under windows 10 with 
the esi Gigaport HD+ audio interface


Hi, usually midi interfaces have little to no latencies, or at least 
they are most likely not your bottleneck. you have to use an ASIO 
driver to get real low latencies on windows systems, or ALSA on Linux. 
It won't work with the standard audio driver (MMIO).


For the Gigaport, i think there is an extra ASIO driver for download, 
but "usually" you will be better off with the ASIO4ALL driver (that 
would even work for your internal audiocard) - at least that's my 
experience with this soundcard on a windows machine.


Having said that, i'm not sure that the "Gigaport HD+" really supports 
low latencies at all. I used it once in an installation and remember 
that i had to use a higher amount of PD's audio delay (= soundcard 
buffer = overall latency) than with other soundcards, maybe a 
trade-off for the 8 channels.


Do you need all of them ? (I guess so ...)

Anyway, try the internal soundcard first and see how low you can get 
without hickups or clicks. to really test latencies i always use a 
test setup like this:


[0.5, 0 1000(
|
[line~]   [noise~]
|  |
[*~    ]
| \
[dac~]

where the midi trigger fires the message box. use your phone recorder 
to measure the "real life" latency between drum pad hit and noise woosh.


just for the record: i'm using a similar setup on an old acer netbook 
with UBUNTU and an old MAYA44USB card and getting very low latencies 
(less than 10ms) using ALSA drivers (PD blocksize 64, PD delay: 8)


i'm pretty sure that it's not your hardware that's lacking, but that 
you have to use a dedicated audio driver (ASIO or ALSA)




best

Oliver





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




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

Re: [PD] PD 0.52 bug ? ... [bang~ driven playback]

[Christof Ressi]

Hi Oliver,

there have been some regressions in Pd 0.52 concerning [readsf~] and 
[writesf~] that should be fixed with 
https://github.com/pure-data/pure-data/pull/1672.


Can you try latest master and see if your problem persists?

Cheers,

Christof

On 05.10.2022 22:01, Dan Wilcox wrote:

Howdy Oliver,

I suggest opening an issue on Github. If this was working with 0.51, 
then my sound file overhaul did not change this but perhaps some 
additional regression fixes broke it in 0.52.



On Oct 5, 2022, at 9:45 PM, pd-list-requ...@lists.iem.at wrote:

Message: 2
Date: Wed, 5 Oct 2022 21:36:19 +0200
From: oliver 
To: Pd-List 
Subject: Re: [PD] PD 0.52 bug ? ... [bang~ driven playback]
Message-ID: 
Content-Type: text/plain; charset=UTF-8; format=flowed

Peter P. wrote:

Oliver,

can't really comment on your error, but am wondering why you might want
to trigger each dsp block separately, especially opening the file from
hard disk for each dsp block over and over again?


i'm using this method quite often for sync purposes (video-synching
mostly, but also sending synch messages with udp etc.), since readsf~
doesn't output it's playback position.

it's also nice, to scratch around in the the audio file without having
to load it into RAM.

As i said before,this method (as strange as it may seem) used to work
without any problem on basically any system i used (even on RPIs and old
slow netbooks) up until PD 0.52.

best

Oliver



Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 




___
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] looking for a simple eq

[Christof Ressi]

that we know from vst-eq-plugins
Then why not use a VST plugin, as suggested by Kaj? Use the right tool 
for the job!


Personally, I tend to use VST plugins for all "conventional" audio 
processing tasks, such as compressor, limiter, EQ, reverb, so I can 
focus on the actual sound synthesis/processing in Pd.


If your patch is supposed to run on a Raspberry Pi, or any other 
platform that does not support VST plugins, that's a different story, of 
course.


Christof

On 28.09.2022 09:13, Jakob Laue wrote:

Hi!
Regarding the UI I had in mind the classical spectogram that we know 
from vst-eq-plugins. But yes, then I also came across the [lop~] and 
[hip~] objects and for now, I can just use a [hslider] and make my own 
little gui with it using canvas. For now, that will suit my needs:)

thanks:)
*Gesendet:* Dienstag, 27. September 2022 um 17:22 Uhr
*Von:* "Lorenzo Sutton" 
*An:* pd-list@lists.iem.at
*Betreff:* Re: [PD] looking for a simple eq
Hi,

On 26/09/2022 18:25, Jakob Laue wrote:
> Dear list,
> I am looking for a simple equalizer abstraction, preferably vanilla, 
but can be part of an external library, too!

>
> Actually I just need simple low-cutting from low to high frequencies 
and/or high-cutting from high to low. A visual representation would be 
great.


Have you tried [lop~] and [hip~]? [bp~] could also come in handy.

What do you mean by visual representation? Of the input vs. output
signal (e.g. a spectrogram)?
Or like a UI for the eq? In that case you could connect some [vslider]
to the objects above?

Hope this helps,
Lorenzo





___
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___
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 ? ...

[Christof Ressi]

Ah, yes. Using Windows VST plugins on a Raspberry Pi is certainly a fun 
idea :-)


Actually, [vstplugin~] has a built-in plugin bridge and winelib is also 
available for ARM, so you would not even need a third-party plugin wrapper.


The first step, however, is to add Linux ARM support to [vstplugin~]. 
This should be rather trivial, given that Apple M1 is already supported. 
Please open a feature request on GitLab!


Christof

On 20.09.2022 15:02, oliver wrote:

Christof Ressi wrote:

Hi Oli,

there is no Linux ARM support for [vstplugin~] (yet). Do you actually 
have any VST plugins that are compiled for this platform?


Actually no, i thought i'd like to try [vstplugin~] first, and see how 
far i will get ;-)


there is an article about using vsts on a PI

https://www.matrixsynth.com/2021/04/how-to-use-windows-vst-plugins-on-linux.html 



so i figured there must be some possibility to do so


will do some more research

anyway, thanks for your quick reply !


best

oliver



___
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] [vstplugin~] on a RPI 3 ? ...

[Christof Ressi]

Hi Oli,

there is no Linux ARM support for [vstplugin~] (yet). Do you actually 
have any VST plugins that are compiled for this platform?


Christof

On 20.09.2022 13:44, Roman Haefeli wrote:

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




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

Re: [PD] nn_tile - search file

[Christof Ressi]

Hi Denis,

open_via_path() only considers the global search paths. You (almost) 
always want to use canvas_open() instead, which also uses the canvas 
environment (i.e. patch relative paths + paths added with [declare]).


Note that you would need a reference to the containing canvas. This can 
be done by calling canvas_getcurrent() in the constructor and storing 
the resulting t_canvas* in the object.


Christof

On 24.08.2022 21:55, Denis Połeć wrote:

Hello,

I am currently experimenting with the external nn_tilde. 
(https://github.com/acids-ircam/nn_tilde) I compiled it for my machine (Apple 
Silicion) and it works so far. It is fun.

There is a little thing which is annoying. I just can load the pretrained 
models with the absolute path. Everything else fails. (declare paths etc) 
This is not really handy.
Does someone face the same problem?

This should be the function which handle the file search. 
(https://github.com/acids-ircam/nn_tilde/blob/master/src/frontend/puredata/nn_tilde/nn_tilde.cpp)
 I can't see any issue.
... Let's say I am not able to see any issue. ;)

  // SEARCH FOR FILE
   if (!sys_isabsolutepath(x->m_path->s_name)) {
 char dirname[MAXPDSTRING], *dummy;
 auto fd = open_via_path("", x->m_path->s_name, "", dirname, ,
 MAXPDSTRING, 1);
 std::string found_path;
 found_path += dirname;
 found_path += "/";
 found_path += x->m_path->s_name;
 x->m_path = gensym(found_path.c_str());
   }

cheers
denis


___
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] C externals in M1 give errors

[Christof Ressi]

Edwin has already pointed out the immediate error in your code.

However, there are a lot more problems. First some general issues:

* you need to free the line buffer before returning from the function, 
otherwise there will be a memory leak.


* AFAICT, the string buffer passed to atoi() is not NULL-terminated. 
atoi() stops after encountering a non-numeric character, so depending on 
the data that happens to be on stack, this might appear to work - but it 
can also easily lead to wrong results!


* The default line ending on Windows is CRLF (13 + 10) instead of just 
LF (10), so depending on how the file was created, your code might not 
work correctly.


Now some remarks about the actual code. IIUC, what you try to do is read 
the content of the text file into a two-dimensional array. Your approach 
seems to be the following: loop backwards character by character and 
manually assemble the decimal numbers from individual digits. First off, 
in this case there is need to call atoi() in the first place because you 
already know the value of the digit. On the other hand, this is 
completely unnecessary becauseatoi() can parse /numbers /- not only 
digits! For example, atoi("1024") will output an integer 1024.


Unfortunately, atoi() has a few problems: it does not handle errors and 
it does not give you the position after the number, so you need to 
manually search for whitespace/newlines. 
https://cplusplus.com/reference/cstdlib/strtol/ solves both issues.


The most idiomatic way for reading a sequence of numbers from a textfile 
in C would be https://cplusplus.com/reference/cstdio/sscanf/. Your code 
could be rewritten as follows:


int readbarfile(int a[][8], FILE *f) {
int row = 0;
char * line = NULL;
size_t len = 0;
while (getline(, , f) != -1) {
int col, value, nread, pos = 0;
for (col = 0; col < 4; col++) {
// We expect 1 converted element.
// (%n does not count, it only tells the current stream position.)
if (sscanf(line + pos, "%d%n", , ) == 1) {
a[row][col] = value;
pos += nread;
} else {
// handle conversion error
}
}
row++;
    }
free(line);
return row;
}

Since you are dealing with a fixed column size, this could be simplified 
further:


int readbarfile(int a[][8], FILE *f) {
int row = 0, col;
char * line = NULL;
size_t len = 0;
while (getline(, , f) != -1) {
// We expect 4 integer items. Actually, we can directly read into the 
output array

// because the data type (int) matches the %d specifier.
if (sscanf(line, "%d%d%d%d", [row][0], [row][1], [row][2], 
[row][3]) != 4) {

// handle error
}
row++;
    }
free(line);
return row;
}

Christof

On 15.08.2022 08:29, Jaime Oliver wrote:

Hi Chris, Brad, All,

I managed to trace the error to the function below. It reads a text 
file and copies its contents to a matrix. The file it's reading is 
always made of lines with the same number of elements like this below:


0 4 4 8 32
1 4 4 8 32
2 4 4 8 32
...

The specific error I'm getting right now is that it is reading that 
number 32 as 29. Again, this same code works fine in all other OSs 
I've tried.


I'm assuming the issue is in the pow() function and all the 
typecasting (int), (double) as Chris suggested?


As for compilation, I am using the latest pd_lib_builder as the makefile.

Thanks for your help!

best,

Jaime

code:

int readbarfile(int a[][8], FILE *f)        {
int i, ii, j, jj, strsize, temp;
char * line = NULL;
size_t len = 0;
ssize_t read;
char ss[10];
temp=j=0;
ii=0;
while ((read = getline(, , f)) != -1) {
jj      = 4;
strsize = (int) read;
for (i=strsize-1; i>=0; i--){
if ( line[i] == (int) 32 || line[i] == (int) 10) { //space or newline
if(i != (strsize-1)) {
a[ii][jj] = temp;
jj--;
                }
j=0;
temp=0;
            }
else     {
ss[0] = line[i];
temp += atoi(ss)*( (int) pow((double)10, (double)j) );
j++;
            }
        }
ii++;
    }
return (ii);
}

On Fri, Aug 12, 2022 at 1:57 PM Chris Clepper  wrote:

That issue only relates to data corruption in the case of major
failures like power loss and kernel panics.  In most of those
situations some data loss is not only expected but also the least
of your concerns.

As for the original topic, the first thing to check is the usual
problems moving between architectures like endianess, definition
of data structures (is long really 32 bits, double 64 bits, etc),
memory alignment and compiler settings.  Does the code work with
all of the optimizations turned off?

On Fri, Aug 12, 2022 at 5:58 AM Bastiaan van den Berg
 wrote:

Did you read that M1's storage has so much cache + lies to the
OS about cache commitments, leading to data corruption
sometimes? https://twitter.com/marcan42/status/1494213855387734019

On Fri, Aug 12, 2022 at 6:14 AM Jaime Oliver
 wrote:

Dear all,

I have a c external that compiles and runs fine on
windows, Linux, and Mac Intel systems, but while the exact
same code 

Re: [PD] A quick question for C dev - temp file on windows

[Christof Ressi]

but sys_bashfilename doesn’t convert the (adequately) created windows separator.
D'oh. I'm sorry, it's the other way round :-D The function you need is 
sys_unbashfilename()


On 23.06.2022 16:54, Pierre Alexandre Tremblay wrote:

Ok the problem is simple: tcl accepts only path separated with ‘/‘ in windows 
but sys_bashfilename doesn’t convert the (adequately) created windows 
separator. So I’ll do a character substitutor.

Objvously the code is free and online so people can have a look or I can post 
here if that helps


On 23 Jun 2022, at 14:48, Christof Ressi  wrote:

Generally, Pd only uses forward slashes as file path seperators. You can use 
sys_bashfilename() on the path generated by tempnam().

On 23.06.2022 15:36, Pierre Alexandre Tremblay wrote:

Hello

In an external I use the superb tmpnam(x) to generate a temp file path to use 
and delete. All is good then… for MacOS and Linux that is! In Windows, the code 
in C does create a file but when I try to pass it to TCL to open there, like in 
the amazing ELSE’s pic, I can’t - the inverted backslash are deleted. I tried 
also, like in else, using open_canvas to no avail.

Now I tried to use on windows the ELSE’s pic to troubleshoot and it seems I 
have 2 problems:

#1:

- PIC will accept the file I create when it is on the Documents folder, but not 
the exact same file in the temp folder created by tmpnam. So this will work:
open C:/Users/pa/Documents/tmp.0.8eDtGO

But not this:
open C:/Users/pa/appData/Local/tmp.0.8eDtGO

===

#2

- PIC will only accept with straight slashes /

C:\Users\pa\Documents\tmp.0.8eDtGO

Won’t work but

C:/Users/pa/Documents/tmp.0.8eDtGO’

will

===

So I wonder if there are pearls of wisdom on temp file generation for cross OS 
compile. At the moment, if I use the PIC hack of going through canvas_open I 
get a ‘void’ name, and if I don’t I get errors due to the backslash not being 
digested by TCL (it seems - the error is as above)

p

Ps Alexandre, without you and your code, this object would not exist, so 
39402940923 thanks!


___
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




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

Re: [PD] A quick question for C dev - temp file on windows

[Christof Ressi]

Generally, Pd only uses forward slashes as file path seperators. You can 
use sys_bashfilename() on the path generated by tempnam().


On 23.06.2022 15:36, Pierre Alexandre Tremblay wrote:

Hello

In an external I use the superb tmpnam(x) to generate a temp file path to use 
and delete. All is good then… for MacOS and Linux that is! In Windows, the code 
in C does create a file but when I try to pass it to TCL to open there, like in 
the amazing ELSE’s pic, I can’t - the inverted backslash are deleted. I tried 
also, like in else, using open_canvas to no avail.

Now I tried to use on windows the ELSE’s pic to troubleshoot and it seems I 
have 2 problems:

#1:

- PIC will accept the file I create when it is on the Documents folder, but not 
the exact same file in the temp folder created by tmpnam. So this will work:
open C:/Users/pa/Documents/tmp.0.8eDtGO

But not this:
open C:/Users/pa/appData/Local/tmp.0.8eDtGO

===

#2

- PIC will only accept with straight slashes /

C:\Users\pa\Documents\tmp.0.8eDtGO

Won’t work but

C:/Users/pa/Documents/tmp.0.8eDtGO’

will

===

So I wonder if there are pearls of wisdom on temp file generation for cross OS 
compile. At the moment, if I use the PIC hack of going through canvas_open I 
get a ‘void’ name, and if I don’t I get errors due to the backslash not being 
digested by TCL (it seems - the error is as above)

p

Ps Alexandre, without you and your code, this object would not exist, so 
39402940923 thanks!


___
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] Call-for-Help: tips of the day

[Christof Ressi]

Sounds great! Thanks a lot!

On 08.06.2022 12:17, IOhannes m zmoelnig wrote:

On 6/8/22 12:11, Christof Ressi wrote:
(like my trusted MS VisualStudio 6) 

Or good old "Clippy" in MS Office :-)

Joking aside, this is really great! I'll certainly contribute.

However, how do people find out about the GUI plugin in the first 
place? I think eventually this has to be shipped with Pd and enabled 
by default, with a simple option to disable it ("Don't show this 
again").



1. yes, my plan is to submit this plugin to the core of Pd (just like 
"deken"), once there's a considerable amount of tips.


2. yes, there's already a checkbox on the dialog to not show the tips 
on startup (but you can re-open it via the help-menu)


3. the plugin also comes with an "Update tips" button, to fetch the 
latest and greatest tips (that weren't even available when you 
installed the plugin (resp. the version that shipped with Pd)


gmasdr
IOhannes




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

Re: [PD] Call-for-Help: tips of the day

[Christof Ressi]

(like my trusted MS VisualStudio 6) 

Or good old "Clippy" in MS Office :-)

Joking aside, this is really great! I'll certainly contribute.

However, how do people find out about the GUI plugin in the first place? 
I think eventually this has to be shipped with Pd and enabled by 
default, with a simple option to disable it ("Don't show this again").


Christof

On 08.06.2022 11:42, IOhannes m zmoelnig wrote:

TL;DR if you know any quick tips for using Pd, submit them at
https://github.com/pd-externals/tipoftheday-plugin/issues/new/choose



long version:

as you all know, Pd comes with a built-in documentation, that 
illustrates how to use various objects and stuff (and alex has done a 
fantastic job in revising these patches in the last months).


for a deeper understanding of Pd, there's the HTML manual (which looks 
nice, after lucarda added some CSS).



however, i think that there are a couple of things that need 
documentation which cannot really be covered by either help patches 
nor manuals.
e.g. "intelligent patching" (where i've spent a bit of time to get it 
working) or other workflow tricks do not fit well in either category:
if they are explained in some help-patches then only people who 
actively walk through those patches will ever see them (and i believe 
most people just open the help-patch of a given object they are 
interested; but what would you open for a non-object that you don't 
even know about).
similarly, i have a feeling that the manual is not the best place for 
this either (first, the manual deals with the "larger picture" rather 
than interface tricks; second, the manual is more of an off-line 
resource (that you may read when not sitting in front of a running 
instance of Pd).


just recently i mentioned the "triggerize" functionality to someone, 
and they never ever heard of it!



to fix this, i've created a small GUI-plugin to display a "tip of the 
day" whenever Pd is started.


i think this (Pd's startup phase) is the right time to learn something 
new (in tiny bits) - after all, other applications (like my trusted MS 
VisualStudio 6) did the same).


the tips are super-simple: just a short text, with an optional URL for 
more information and support for displaying (animated) GIFs (patching 
is oft explained better by showing).



the GUI-plugin is available on
  https://github.com/pd-externals/tipoftheday-plugin/

but there's no release (and thus no deken package) yet.

There's also an experimental webinterface where you can browse the 
existing tips at 



so far so good.
The only drawback right now is, that there are only a very few tips 
available yet (a total of *4*, mainly for testing).


so before this is going to be released to the public, I'd like to 
collect a few (hundred) more tips


this is where you come into play:
if you know any quick tips, patching tricks or hacks, please submit 
them in the issue-tracker at 

(the "Tip of the Day" issue-type will give you a form that you should 
fill in; this should keep the entry barrier to creating new tips low).



thanks for helping out.

gmasdr
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