the meaning of PD_VERSION_CODE is really "a single code(number)
expression the (entire) version of Pd", and belongs into the same
family as PD_VERSION_MAJOR ("a single (code)number expression the
major version of Pd").
having PD_VERSION_MAJOR and PD_CODE_VERSION adds additional mental
load
Actually, I have quite a few other multi-channel PRs. I think Miller
just didn't have time to review them. I guess we just have to wait for
Pd 0.56 :)
PS: we should also discuss or make PRs for some other essential missing
multichannel features, see
On 25.04.2024 17:41, IOhannes m zmoelnig wrote:
On 4/25/24 16:24, Christof Ressi wrote:
Thanks for restoring my sanity :)
however, there *is* a regression, as the DSP toggle is not turned on
if the DSP is started with loadbang.
Yes, but that one is not related to my scheduler updates
need to have a look at your code, ...
sure:
https://git.nubegris.com.ar/lucarda/pdvst-0.52/src/branch/sq-fudi/vst-scheduler/vstschedlib.c
you could also see the "master" branch but as mentioned it also
exhibits the issue.
--
Mensaje telepatico asistido por maquinas.
On 24
On 24.04.2024 09:45, Lucas Cordiviola wrote:
Hi,
I'm working with some new feature of pdvst~
(https://git.nubegris.com.ar/lucarda/pdvst-0.52/compare/master...sq-fudi)
this runs Pd via external scheduler "vstscheduler.dll"
I hit some strange issue with current Pd (Merge branch
(taking it back to the list)
So, just to be clear, are you actually saying that PD's audio
internals *are* multi-threaded?
Of course they are! Otherwise we wouldn't need the lockfree ringbuffer :)
The only occurrences I find in (0.53.1) of pthread_create() are in
d_fft_fftsg.c and
That's my fault. I did not have much time when I did that update, so I
just found the equivalent functions without changing anything to be
conservative. If you have suggestions for improvement, I am open to
it. We can also ping Peter.
No worries! Actually, I always meant to do a PR. Will do
en.cppreference.com/w/c/thread)
Christof
On 11.04.2024 14:08, Caoimhe wrote:
On Thu, 11 Apr 2024 at 07:52, Christof Ressi
wrote:
> I get at least four threads. Just for some context: here on Windows
I get 10 threads when I open Pd and start DSP, but only 2 of these are
active and the remaini
Hi,
I get at least four threads
Just for some context: here on Windows I get 10 threads when I open Pd
and start DSP, but only 2 of these are active and the remaining 8 or idle.
The Pd core itself does not spawn any threads, only the audio backend
and certain objects/externals do (notably
r. Then it has been in testing for a *long* time now. ;)
On Mar 14, 2024, at 1:44 PM, Christof Ressi
wrote:
I think Antoine's knob implementation is actually based on mknob,
but with lots of refinements.
On 14.03.2024 13:39, Dan Wilcox wrote:
I agree.
There is also the mknob from moonlib whi
with the other IEM guis.
On Mar 14, 2024, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote:
Date: Wed, 13 Mar 2024 13:10:19 +0100
From: Christof Ressi
To:pd-dev@lists.iem.at
Subject: Re: [PD-dev] release April?
Message-ID:
Content-Type: text/plain; charset="utf-8"; Format="flowed"
I s
I strongly endorse both PRs :)
Fractional zoom levels would be a game changer! The current integer zoom
levels are pretty much useless in practice because typical scaling
factors are more like 125% or 150%.
A knob is such a basic UI element for audio applications. I really think
this should
nto master once 0.55 is out. (and yes, I'm imagining numbering it
0.55). But I can be flexible on all of this.
I'll look at the PRs suggested below... they all sound worthwhile.
cheers
Miller
On 3/12/24 11:49, Christof Ressi wrote:
Hi Miller,
good to hear from you!
Just a question: since
Hi Miller,
good to hear from you!
Just a question: since you plan to add new features, this would be Pd
0.55 - and not Pd 0.54.2 - right?
I'm thinking of making a release mid April (assuming things go well)
and so I should probably call for a freeze late March.
That's a pretty narrow merge
blay wrote:
This is by far the best explanation of symbols I’ve read, ever.
Thanks!
On 22 Feb 2024, at 13:41, Christof Ressi wrote:
Hi,
Pd symbols are immutable and permanent. `gensym("foo")` looks if the symbol
"foo" already exists; if yes, it just returns it, otherwise
Hi,
Pd symbols are immutable and permanent. `gensym("foo")` looks if the
symbol "foo" already exists; if yes, it just returns it, otherwise it
creates a new symbol, adds it to the global symbol table and finally
returns it.
You must never attempt to free a symbol!
```
t_symbol
Can anyone point me on a direction to make an artificial larger block
from an 64 block?
You just have to buffer the incoming samples and only do the DSP once
the buffer is full. Rinse and repeat.
Any object as an example I should see?
Have a look at [env~].
Christof
On 23.11.2023 16:25,
CLASS_SIGNALMAININ expects the variable to be t_float, but x_cf is
declared as a double! The compiler happily accepts it and you get
garbage at runtime! In this particular case, Pd would read the lower
half of the double and interpret it as a float.
Actually, there are ways to check the type
the help.
Alexandros
On 9/23/23 11:39, Christof Ressi wrote:
So you're saying that I only need to do the initial allocation, like
this:
`x->x_in = (t_sample **)getbytes(ninlets * sizeof(t_sample *));`
and not try to allocate `t_sample *` bytes in the for loop? I did
try this, but ag
So you're saying that I only need to do the initial allocation, like
this:
`x->x_in = (t_sample **)getbytes(ninlets * sizeof(t_sample *));`
and not try to allocate `t_sample *` bytes in the for loop? I did try
this, but again the object is crushing.
Yes, because "x_in" and "x_out" are
I'm pretty sure it's because x_blksize is 0. (Internally, getbytes()
always allocates at least 1 byte, which explains why you can
successfully access the first sample.)
In the new routine, I allocate memory likes this:
In the new routine, you may only allocate the vectors that hold the
.com/pure-data/externals-howto#gensym does not really
belong to the "atoms" sections...
Christof
On 21.09.2023 10:23, Christof Ressi wrote:
I've tried `t_symbol *s = atom_gensym("foo")`
Where do you see "atom_gensym"? I guess you confused it with
"atom_getsymbol
ensym("foo")` but I get a warning the
atom_gensym() expects a const t_atom *a, and when I pass `s` to the
second argument of outlet_anything and print the output, I get "???"
instead of "foo". This might be obvious, but it's quite complicated to me.
On 9/
`outlet_list(x->outlist, _list, 3, x->outlist)`;
You accidentally passed the outlet itself as the last argument (t_atom
*) to outlet_list().
Unfortunately, C only offers minimal type checking and happily casts
between unrelated pointer types. (With C++ this wouldn't compile in the
first
what is this "2" supposed to represent?
This looks like a mistake to me. The buffer certainly does not have to
be twice as large, as it is only used to copy the input.
To solve the mystery, you don't allocate the right amount of memory
because you forgot about the element type:
x->bufbytes
cessary.
Christof
On 24.08.2023 16:48, Day Rush wrote:
On Thu, 24 Aug 2023 at 14:12, Christof Ressi
wrote:
Perhaps. But I was definitely able to manually bump the priority
without sudo.
I don't doubt that you can manually bump the priority; that
doesn't necessarily mean that Pd
k that multi-threaded
DSP is really orthogonal to the problem you have described in your last
e-mail.
Christof
On 24.08.2023 14:14, Day Rush wrote:
On Wed, 23 Aug 2023 at 23:24, Christof Ressi
wrote:
I actually get fewer xruns in callback mode,
This sounds highly unlikely. Maybe
Best regards,
Joseph
Le 22/08/2023 à 17:22, Christof Ressi a écrit :
I've always been puzzled by the fact that everything runs on a
single thread in Pd.
By default, Pd operates in "polling mode", i.e. the scheduler
runs in its own thread (the main thre
functions *not* call when DSP is running.
On Aug 23, 2023, at 5:30 PM, Christof Ressi
wrote:
so it would pay to fill out the header.
Yeah, all API functions in "m_pd.h" should really have minimal
documentation (preferrably doxygen).
However, I'm not sure that "m_pd.h"
5:05 PM, pd-dev-requ...@lists.iem.at wrote:
Message: 1
Date: Wed, 23 Aug 2023 17:04:41 +0200
From: Christof Ressi
To:pd-dev@lists.iem.at
Subject: Re: [PD-dev] why must one never send a message from a perform
routine ?
Message-ID: <7a96c4d0-10ec-1d18-b016-df0304498...@christofressi.com>
in detail, and I hope this will benefit other users on the list.
Best regards,
Joseph
Le 22/08/2023 à 17:22, Christof Ressi a écrit :
I've always been puzzled by the fact that everything runs on a
single thread in Pd.
By default, Pd operates in "polling mode", i.e. the scheduler run
f.
I'll probably give your version a try if I hit the limits with my
current (rapidly growing) project running on a Pi 3 B+, but can't make
any promises with my current schedule.
Thanks for your work anyways.
Best,
Joseph Larralde
--
freelance developer
www.josephlarralde.fr
Le 22/08/2023 à 11:
-channel, so I'm wondering if I could get away with using your
tree as my basis for a while :)
- d
On Tue, 22 Aug 2023 at 01:17, Christof Ressi
wrote:
To expand on Miller's reply:
Conceptually, messaging and DSP are two separate domains. Sending a
message from a perform routine
To expand on Miller's reply:
Conceptually, messaging and DSP are two separate domains. Sending a
message from a perform routine violates this separation. Instead you
should use a clock with delay 0 to defer the message to the begin of the
next scheduler tick.
Miller already mentioned the
Hi,
the problem is here:
https://github.com/porres/pd-else/blob/2d53dfa7bd02b1fd102dbad7a2f9799df0a32e37/Code_source/Compiled/signal/xgate.mc~.c#L67-L68
signal_setmultiout() changes the signal pointer, so you must call it
/before /assigning the signal pointer to the arg vector for dsp_addv()!
s my new attempt, hopefully not too far from getting
things right
https://github.com/porres/pd-else/blob/master/Code_source/Compiled/signal/remap~.c#L34
cheers
Em sáb., 22 de jul. de 2023 às 21:02, Alexandre Torres Porres
escreveu:
Em sáb.,
Hi,
if the input and output signals have the same channel count, they will
alias each other, just like in regular single-channel objects. In that
case, your code may accidentally overwrite parts of the input before it
is read. You first need to copy the whole input signal to a temporary
Hi,
2. "Wipe prefs"
we can add
[ ] clear Pd prefs and exit (try this if Pd is not loading anymore)
I think that's a good idea and I was already going to suggest something
like this.
3. "make the uninstaller recursively delete install path"
Yes, we should definitely do this.
Christof
I'm having trouble getting "oss MIDI" (that is, access to /dev/midi*)
working in linux. Whereas in 0.53 I get choices "none", "/dev/midi3",
"/dev/midi4", "/dev/midi5", on 0.54 I get an extra entry, "(no
device)". When I select "midi4" for example, the next time I open the
dialog it shows
PS: there's also some more of my PRs which i would like to draw
special attention to (for inclusion with Pd-0.54)
To follow up, it would be great if Pd 0.54 could include my scheduler
fixes/improvements:
https://github.com/pure-data/pure-data/pull/1756
It has been tested by several people on
if it is worth it, I don't have an account there.
Bye
Le jeu. 18 mai 2023 à 13:37, Christof Ressi a
écrit :
Hi,
yes, "make app" strips the binaries by default.
Since autotools/libtool is incredibly slow on Windows, I typically
only
do "make app" once in
Hi,
yes, "make app" strips the binaries by default.
Since autotools/libtool is incredibly slow on Windows, I typically only
do "make app" once in the beginning; in my IDE I have a added a custom
build step "cp ./src/pd.dll ./pd-0.x.x/bin" that just copies the
(unstripped) Pd DLL into the bin
Hi,
I consider it to be a very useful (and basic) feature,
Actually, it is not a basic feature at all, that's why it is better to
keep it out of the Pd core.
Also, there are few other (more modern) VST wrapper projects, e.g.
Camomile and PlugData.
Christof
On 09.03.2023 10:51, Jorge W
Yup. Otherwise you’ll open the help file and think there’s a bug.
But that does not really mean that cyclone as a whole *requires* Pd
0.53-2. It is really a minor issue. If you say "cyclone requires Pd
0.53-2", then people will think that it does not work at all with older
Pd versions and
of pushing directly to master.
But this is just a suggestion. I just think that it could help avoid
tricky situations like this in the future.
Christof
On 06.02.2023 23:47, IOhannes m zmölnig wrote:
On 2/6/23 23:07, Christof Ressi wrote:
Afterwards, maybe current development can
Afterwards, maybe current development can be in the branch until
ready, ie. feature/multi-channel or develop/0.54, etc?
That's what I would suggest in general.
It would be great if all new features, rewrites, experiments, etc. could
be made in feature branches. This has several advantages:
That would be great a feature! I think many of us have thought about
that, but nobody has made a PR yet.
I think the easiest solution would be to add more options to [print]. I
particularly like the idea that [print] could (optionally) set the
containing abstraction as the error source.
You
Also, I can confirm that the 0.52-2 branch (with ASIO/portaudio support)
compiles just fine.
On 05.02.2023 22:56, Christof Ressi wrote:
it's compiling just fine here using mingw so it's probably something
stupid.
Are you building with ASIO support?
./configure --enable-portaudio --enable
it's compiling just fine here using mingw so it's probably something stupid.
Are you building with ASIO support?
./configure --enable-portaudio --enable-asio -> FAIL
./configure --enable-portaudio --disable-asio -> FAIL
./configure --disable-portaudio -> SUCCESS
Christof
On 05.02.2023
Meanwhile there's Christof's semaphor feature which promises to lower latency
(I tried doing this earlier in s_audio_pa.c but found it actually increased
latency; not sure what's going on here).
I guess you are talking about the THREADSIGNAL part (which has never
been enabled, except for a
The implementation of signal_setoutchans() looks good to me! There is
indeed no danger of breaking signal aliasing. Since the dummy output
signals are "empty" (s_nchans = 0), they are allocated from the "borrow"
free list and not from the "real" free list. Nice :-)
I think
output signals (channels=length=vec=0)
and instead of (for example)
sp[2] = signal_swapforchans(sp[2], outchans);
you'd just write
signal_setchans(sp[2], ouchans).
cheers
Miller
On Wed, Jan 25, 2023 at 03:42:15PM +0100, Christof Ressi wrote:
Cool!
I don't see these changes yet. Did you
Cool!
I don't see these changes yet. Did you forget to push them or are you
still working on it?
(I am working on some clone multi-channel bugfixes and I would need the
new signal_swapforchans() function :-)
Christof
On 25.01.2023 05:46, Miller Puckette via Pd-dev wrote:
OK, just now
I'm hesitating between "snake~ in", "snake~ out" and
"snake~ tap"
or "join~", "split~", and "tap~"...
Former is more colorful (and crowds the namespace less). Latter
might be
easier for non-native English speakers to
Hi all,
I am a bit late to the party. I finally got around studying the new
multichannel code changes and wading through this massive sea of e-mails
to get up to date on the discussion :-)
First off, I am very excited about this new feature! Here are a few
comments from my side. The e-mail
Isn't "mux~/demux~" closest to what's actually happening?
Unfortunately, these are also zexy objects ;-)
On 24.01.2023 11:52, Max wrote:
Isn't "mux~/demux~" closest to what's actually happening?
when "joining" two signals, I wouldn't expect them to be running in
parallel but being mixed
On 17.01.2023 21:06, Jakob Skouborg wrote:
Do you for example know if there is a block of delay added to catch~
or tabsend~, like Miller mentioned there would be if the symbol naming
feature was added to send~?
There would be no extra block of delay for [send~]. I suspect Miller was
really
it?
Em ter., 17 de jan. de 2023 às 16:44, Christof Ressi
escreveu:
I see, I wonder why exactly you need this, like a specific use
case.
One concrete example: you have a modular system where the output
of an abstraction may be used by other abstractions, but they do
not know
are settable :-) Also, they work at any block size.
On 17.01.2023 20:47, Alexandre Torres Porres wrote:
so, [throw~] can set the destination, why not use it?
Em ter., 17 de jan. de 2023 às 16:44, Christof Ressi
escreveu:
I see, I wonder why exactly you need this, like a specific use case
I see, I wonder why exactly you need this, like a specific use case.
One concrete example: you have a modular system where the output of an
abstraction may be used by other abstractions, but they do not know
anything about each other. For this you might want to use a [send~] and
[receive~]
of
the external:
https://www.dropbox.com/s/v45itm3lrwsxaax/leapmotion.zip?dl=0
On Thu, Jan 5, 2023 at 10:21 AM Christof Ressi
wrote:
> so...just one last question (hopefully): what's the best
practice for
> packaging an external like this? The dependencies are:
kernel
If you want to learn the ugly details:
https://learn.microsoft.com/en-us/cpp/windows/deploying-native-desktop-applications-visual-cpp?source=recommendations=msvc-170
On 05.01.2023 16:20, Christof Ressi wrote:
so...just one last question (hopefully): what's the best practice for
packaging
so...just one last question (hopefully): what's the best practice for
packaging an external like this? The dependencies are:
kernel32.dll is always present and must not be distributed.
msvcp140d.dll, ucrtbase.dll and vcruntime140*.dll are Microsoft C
runtime libraries.
Can you send me the
k of...any ideas?
On Tue, Jan 3, 2023 at 4:19 PM Christof Ressi
wrote:
To be more specific, the linker error itself is most likely caused
by name mangling differences. When you include the header file in
your project, the class/function definitions use /your /compiler's
nam
To be more specific, the linker error itself is most likely caused by
name mangling differences. When you include the header file in your
project, the class/function definitions use /your /compiler's name
mangling, but the accompanying DLL has been built with /another
/compiler, using a
That said, would it be worth my time to try and set up a Visual Studio
project and build against the old C++ library there?
If you use CMake, you only have to specify the appropriate Visual Studio
generator. That's it. You build your project with
cmake --build .
and it will automatically
Hi Dan,
that's just great! Thanks a lot for sharing!
Cheers,
Christof
On 28.10.2022 14:58, Dan Wilcox wrote:
Howdy all,
I've been working on a single solution for creating distribution
packages for macOS which automates the whole code signing and
notarization process. What I have so far
Personally, I would keep s_n as the number of samples /per channel/.
The total number of samples is simply s_n * s_nchans. Existing
externals - that do not know about s_nchans - would effectively
operate on the first
i think the idea is that with "s_n = s_nchans * s_length" existing
Hi Miller,
this sounds great! First-class multi-channel support would be a real
game changer.
Actually, after Winfried Ritsch told me about the "pd_snake" project, I
came up with a couple of ideas on my own. You can find them here:
When you start Pd through Rosetta (by right-clicking the app-icon and
selectign "Open using Rosetta"), you instruct the OS to launch the
Pd-GUI through rosetta.
The Pd-GUI then starts the Pd-core, and doesn't care a bit about your
rosetta-settings, which means that the Pd-core is started in
On 04.04.2022 15:49, Antoine Rousseau wrote:
ABI break for multi-instance libpd
only externals already compiled for multi-instance would have to be
recompiled, I think.
That's what I meant.
And it wouldn't allow current externals to be used in a multi-instance
context.
But it would
/vstplugin~.cpp
Of course, such externals would just need to be recompiled, but it is
something to be aware of.
---
Conclusion: "secretly" enabling PDINSTANCE for regular Pd builds can
break existing externals in unexpected ways.
Christof
On 04.04.2022 15:00, Christof Ressi wrot
myfloat;
int main()
{
libpd_init();
printf("myfloat: %f\n", myfloat);
}
cc -I../../../libpd_wrapper -I../../../pure-data/src -O3 -c -o
pdtest.o pdtest.c
gcc -o pdtest pdtest.o ../../../libs/libpd.so
$ pdtest
pdinstance_init::myfloat: 20.0
myfloat: 10.0
Do you know wh
AFAICT, the main issue is that multi-instance Pd misses symbols for
certain global variables, most notably s_float, s_symbol, s_bang, etc.
The problem is that these are really exported global structs. If they
were *pointers*, we could simply make them point to the corresponding
field in the
On 30.03.2022 17:40, IOhannes m zmoelnig wrote:
On 3/30/22 17:21, Christof Ressi wrote:
but i don't really see how it would help with fat binaries.
Two solutions that come to my mind:
1) just use an ugly folder name:
foo.pd/darwin-amd64-32.darwin-arm64-32/foo.dylib
the problem
-32/foo.dylib
On 30.03.2022 16:33, IOhannes m zmoelnig wrote:
On 3/30/22 16:16, Christof Ressi wrote:
i do not want to have zexy.darwin-amd64-32.darwin-arm64-32.so
maybe a bundle structure (as described in
https://lists.puredata.info/pipermail/pd-dev/2022-03/022997.html)
might
i do not want to have zexy.darwin-amd64-32.darwin-arm64-32.so
maybe a bundle structure (as described in
https://lists.puredata.info/pipermail/pd-dev/2022-03/022997.html) might
not be such a bad idea after all?
___
Pd-dev mailing list
might be overkill...
Christof
On 29.03.2022 17:49, Roman Haefeli wrote:
On Tue, 2022-03-29 at 17:29 +0200, Christof Ressi wrote:
+1
+1
I think it's nicer to use a common extension and have the
platform/arch/floatsize specifier as a seperate component.
I didn't especially like this back then,
+1
I think it's nicer to use a common extension and have the
platform/arch/floatsize specifier as a seperate component.
On 29.03.2022 11:28, IOhannes m zmoelnig wrote:
hi,
TL;DR i'd like to suggest to use deken-specifiers as (optional) part
of external filenames, in order to allow
didactically.
cheers
Miller
On Mon, Mar 28, 2022 at 11:20:23AM +0200, Christof Ressi wrote:
As others have said, Pd originally only used ASCII mode and binary mode
has been introduced later to avoid loss of precision. The ASCII mode has
not been designed to help with debugging.
As Miller said
As others have said, Pd originally only used ASCII mode and binary mode
has been introduced later to avoid loss of precision. The ASCII mode has
not been designed to help with debugging.
As Miller said, there is no real reason to ever use "-ascii". I don't
think we need to document it at all.
'sigvec' is declared as t_int ** and is used in
*dsp_addv(chance_perform, n_sig, (t_int *)sigvec);*
dsp_addv wants "t_int *" (= an array of t_int), not "t_int **", so
sigvec must be "t_int *" as well. Consequently, variables must be cast
to "t_int", not "t_int *", when assigning to the array.
Also, I would be happy to see integrating more modern backends for
Windows, ala the portaudio waspi implementation.
Yes, I already mentioned this.
Note that WASAPI is only supported on Windows Vista and above. I think
it's fair to require at least Windows 7 for the 64-bit Windows builds.
The
Message-ID:
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 1/21/22 14:59, Christof Ressi wrote:
What about my proposition to include portaudio as a submodule
in general i do not like git submodules.
first of all they make problems when using 'git archive
2nd, submodules do not allow for patching the vendored sources (e.g.
we *could* remove the annoying printout at Pa_Initialize() in our
vendored copy, but not with 'git submodule').
Actually, you can commit changes to a submodule:
https://stackoverflow.com/a/5542964/6063908. However, it's
it happens at initialization time.
e.g. when i start "audacity".
there are no problems when i turn on DSP (or in audacity: when i start
playback)
That's interesting. I really never experienced/noticed this. If you have
time, check if this still happens with the latest portaudio release and
What about OSS? I understand that it's legacy, so maybe we can just
use the portaudio implementation?
i think the merit of OSS is that it allows to build Pd with *zero*
external dependencies and still have sound (and MIDI): no libalsa, no
libjack.
this is probably also the most
Thanks for your replies!
minor side-note: ESD is just a dummy.
the Enlightened Sound Daemon died some decade ago.
i'm not sure the Pd backend was ever used.
it should be removed.
Yes, this is what I got as well.
i never use portaudio, as it never really *worked* for me.
From what I read
Hi,
here's a question that has been bugging me for quite a while: Why do we
keep all those individual audio backends instead of just using portaudio
everywhere? Are there any other reasons *besides* backwards
compatibility with existing setups (saved preferences)?
Currently we have the
and will keep it your way
to make sure I keep seeing the problem :)
cheers
Miller
On Fri, Dec 03, 2021 at 11:06:54AM +0100, Christof Ressi wrote:
IOhannes has the answer: the resulting string might not be valid Tcl
variable name.
For further discussion see:
https://urldefense.proofpoint.com/v2/url?u
I presume there's a good reason to change the code (what if "long" is the wrong
size?) but I'd like to figure out a way to do it that doesn't throw warnings.
Ok, now I understand the reason for those few (unsigned long) casts.
It's because the printf() family functions will check the format
IOhannes has the answer: the resulting string might not be valid Tcl
variable name.
For further discussion see:
https://github.com/pure-data/pure-data/issues/1474#issuecomment-985386181
On 03.12.2021 10:39, Christof Ressi wrote:
NOTE: although %p would be the obvious choice, we can't use
forgot why this would be a problem... the
IDs are only generated in the core and GUI app shouldn't care.
So Albert is right, why don't we use %p everywhere?
Christof
On 03.12.2021 10:34, Christof Ressi wrote:
I presume there's a good reason to change the code (what if "long" is
the
Usually, we would use flags, e.g. in your case something like "-heap
".
[sigmund~] object, for example, takes a few flag arguments. You can take
it as a reference point.
Christof
On 24.09.2021 17:33, Iain Duncan wrote:
Hi folks, I want to add an optional argument for object creation time
The thing is that when you're designing the abstraction, before it
exists, when you're bringing it to life, in its creation process, you
might be working on it under the top level,
I see!
and it's annoying to have the object not created.
IMO, there is no reason why an object should refuse
Yes, that's the problem. I should have said it all works fine if this
is an abstraction loaded with actual arguments. But I still wonder if
there's anything I can do.
There is: just don't do it :-) It doesn't make sense to use $1 in the
context of a top-level canvas (until we get
Hi, when using A_GIMME I can test if the type is A_FLOAT or A_SYMBOL,
but if I give it a "$1", for instance, it's treated as a float.
Well, it depends on the actual value of "$1". In the case of
[cyclone/play~ $1], the "$1" is replaced by its actual value before
being passed to the object.
Maybe IOhannes & Christof can give their take? Also, I believe the PR
includes a compile-time define to enable/disable.
I think the PR is already in very good shape. The public API functions
(in s_stuff.h) look reasonable. I have to admit I haven't checked the
most recent commits yet, but I'll
However, it would only show the dialog for a split second and the
crash. I ran it in a debugger and just get a completely wiped stack.
If I remove the "quit" message, it works.
you only have to run the exploit.pd once (and it will always quit Pd).
the next time you simply start Pd, you
bugger and just get a completely wiped stack. If I
remove the "quit" message, it works.
So how do I pay the money?
Christof
On 31.08.2021 15:49, IOhannes m zmoelnig wrote:
On 8/31/21 3:12 PM, Christof Ressi wrote:
The exploit successfully changes my MIDI settings and adds search
paths
1 - 100 of 269 matches
Mail list logo
