+1 to having them in the docs but clearly labelled as something along the
lines of "not in the public API - may change without notice". That kind of
stuff is really helpful to people coming up on the whole system to better
understand how it all works.
my two cents Canadian. :-)
On Fri, Nov 26,
Em sex., 26 de nov. de 2021 às 20:19, João Pais
escreveu:
> I don't see a mention to these messages: mouse, mouseup, mousedown,
> relocate. And also all other messages related to gui stuff.
>
yeah, I didn't put it. It felt like something hard to document and for more
extreme cases. And now that
I don't see a mention to these messages: mouse, mouseup, mousedown,
relocate. And also all other messages related to gui stuff.
It could also be clearly mentioned that subpatches receive messages sent
to pd-[subpatch], and abstractions are named [abstraction].pd (if I'm
recalling correctly) -
Em sex., 26 de nov. de 2021 às 17:18, Christof Ressi
escreveu:
> don't advertize "coords" (at least you didn't mention "donecanvasdialog")
> because that one should really be replaced by
> https://github.com/pure-data/pure-data/pull/627 (hopefully in the next Pd
> release :-)
>
yeah, makes sense
> In particular, please don't include any GUI dialog messages
which are they all?
anyway, I felt I was crossing a line, hence I'm waving here to the judges
:)
For instance, [namecanvas] did include a 'msg' message to canvas. I count
that as a modest dynamic patch documentation.
Also, many of
I think there are definitely many "official" messages (e.g. "dsp",
"fast-forward", "quit", etc.) that need to be documented properly, so in
principle I very much welcome this effort.
However, I'm rather sceptical about including any "dynamic patching"
messages in the official documentation as
new commit, forgot about 'dirty'
https://github.com/pure-data/pure-data/pull/1455/commits/8fe7ff12419c797bf33e6ff0409798d089dfba25
patch attached
Em sex., 26 de nov. de 2021 às 17:05, Alexandre Torres Porres <
por...@gmail.com> escreveu:
> the reason I ask for revisions here is that I'm not an
the reason I ask for revisions here is that I'm not an expert on this dark
magic, so I'm not 100% sure about things. I can revert the commit in the PR
and keep it on the fridge for the next release update if the real wizards
see problems on it.
Em sex., 26 de nov. de 2021 às 16:59, Alexandre
People, I'm on a roll here, updating much of the help files and
documentation.
I just hit an important new addition, documenting "Messages to/from Pd" and
"Dynamic Patching"
I'd like you people to revise it.
Here's the commit =>
On 26.11.2021 17:52, IOhannes m zmölnig wrote:
Am 26. November 2021 17:39:09 MEZ schrieb Christof Ressi
:
@christof Deken is prepared for that.
"vstplugin~[v0.5.3](Windows-amd64-32).dek". See the last -32 should be
-64 for double.
Ah, I didn't realize! That's cool! So that part is already
Em sex., 26 de nov. de 2021 às 13:54, IOhannes m zmölnig
escreveu:
> From my perspective the main problem is co-instability of externals of
> multiple float sizes: currently if Pd loads an external with the wrong
> float size, it will stop searching for another external (that might load
> the
On 11/26/2021 1:36 PM, Alexandre Torres Porres wrote:
and the binary is "ceammc.d_amd64"
To avoid confusion this is default extension for Pd on 64bit Arch. Not a
"double precision" one.
see http://msp.ucsd.edu/Pd_documentation/x4.htm#s1.2.1
Mensaje telepatico asistido por maquinas.
Am 26. November 2021 17:39:09 MEZ schrieb Christof Ressi
:
>
>>
>> @christof Deken is prepared for that.
>> "vstplugin~[v0.5.3](Windows-amd64-32).dek". See the last -32 should be
>> -64 for double.
>>
>Ah, I didn't realize! That's cool! So that part is already solved :-)
>This was actually my
If precision does not match Pd refuse to load (IIRC).
correction: Pd refuses to load the external.
--
Mensaje telepatico asistido por maquinas.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
Em sex., 26 de nov. de 2021 às 13:41, Christof Ressi
escreveu:
> On 26.11.2021 17:30, Lucas Cordiviola wrote:
>
> @porres Pd-ceammc builds Pd and their externals (for double) using default
> file extension.
>
> @christof Deken is prepared for that.
> "vstplugin~[v0.5.3](Windows-amd64-32).dek".
What am I risking in getting ceammc from deken in my double precision
build?
Nothing. Perhaps it overwrites you single precision ceammc folder. If
precision does not match Pd refuse to load (IIRC).
--
Mensaje telepatico asistido por maquinas.
On 11/26/2021 1:36 PM, Alexandre Torres
On 26.11.2021 17:30, Lucas Cordiviola wrote:
@porres Pd-ceammc builds Pd and their externals (for double) using
default file extension.
@christof Deken is prepared for that.
"vstplugin~[v0.5.3](Windows-amd64-32).dek". See the last -32 should be
-64 for double.
Ah, I didn't realize! That's
Em sex., 26 de nov. de 2021 às 13:33, Lucas Cordiviola <
lucard...@hotmail.com> escreveu:
> @porres Pd-ceammc builds Pd and their externals (for double) using default
> file extension.
>
> @christof Deken is prepared for that.
> "vstplugin~[v0.5.3](Windows-amd64-32).dek". See the last -32 should
@porres Pd-ceammc builds Pd and their externals (for double) using
default file extension.
@christof Deken is prepared for that.
"vstplugin~[v0.5.3](Windows-amd64-32).dek". See the last -32 should be
-64 for double.
--
Mensaje telepatico asistido por maquinas.
On 11/26/2021 1:17 PM,
Em sex., 26 de nov. de 2021 às 13:19, Christof Ressi
escreveu:
> On the other hand, we *could* release double precision Pd without official
> support for externals. I'm just not sure if this is a good idea...
>
That seems harmless to me. I remember when the first 64 bit builds of Pd
came around
As I see it, one can already build FAT externals if they want to.
No, you can't. I think you're confusing this with fat binaries on macOS
containing different architectures (which is not related).
At the moment, there is just no "official" strategy how to handle double
precision externals. Of
Em sex., 26 de nov. de 2021 às 10:50, Christof Ressi
escreveu:
> @Lucarda Thanks for the link!
>
> There is some more discussion in the linked issue:
> https://github.com/pure-data/pure-data/issues/900
>
> @porres As you can see, there are practical problems which need to be
> solved before
@Lucarda Thanks for the link!
There is some more discussion in the linked issue:
https://github.com/pure-data/pure-data/issues/900
@porres As you can see, there are practical problems which need to be
solved before making it official.
Anyway, I think it's a good idea to start discussing
On 11/26/2021 8:48 AM, Alexandre Torres Porres wrote:
Can you pinpoint the issue? what do we have to decide on externals?
ceammc already offers a double precision download for vanilla, I would
also like to start providing my externals for that too (cyclone/ELSE).
What do I need to do?
Can you pinpoint the issue? what do we have to decide on externals?
ceammc already offers a double precision download for vanilla, I would also
like to start providing my externals for that too (cyclone/ELSE).
What do I need to do?
cheers
Em sex., 26 de nov. de 2021 às 07:50, Christof Ressi
I think before we start supporting double precision Pd "officially",
there are still a few things to sort out, particulary how to deal with
externals. This has been discussed a few times on the list, but there is
no real consensus yet. So I think for Pd 0.52 it's too early.
On 26.11.2021
Em sex., 26 de nov. de 2021 às 05:56, hans w. koch
escreveu:
> nothing against a pre compiled binary, but considering that even i am able
> to roll that for myself, i wonder if thats really necessary.
>
it is :)
___
Pd-list@lists.iem.at mailing list
nothing against a pre compiled binary, but considering that even i am able to
roll that for myself, i wonder if thats really necessary.
with the right tools installed (explained in install.txt) , i use this:
cd path/to/pd
./autogen.sh
./configure CPPFLAGS="-DPD_FLOATSIZE=64"
make
28 matches
Mail list logo
