Re: [PD-dev] release April?

[Antoine Rousseau]

Miller,

Could I also have your feelings about these 2 PR:

- https://github.com/pure-data/pure-data/pull/1659: modern canvas zoom and
scroll
- https://github.com/pure-data/pure-data/pull/1738: round knob GUI

thanks!

Antoine


Le mar. 12 mars 2024 à 08:47, Miller Puckette  a
écrit :

> To Pd dev -
>
> I'm thinking of making a release mid April (assuming things go well) and
> so I should probably call for a freeze late March.  As usual I plan to
> merge in "devel" and "Documentation" - in fact I should do a first merge
> rather soon, assuming things are in a good state for merging.
>
> I'm planning to add a couple of features: 1. message to Pd to toggle
> between GUI and no-GUI -- perhaps with a way to reset the GUI startup
> command -- so that if you have a headless installation that's doing
> something funny you can pop it open and look; and 2. improvements to the
> "pointer" object to make it easier to get around data structures, and
> possibly a menu extension for dragging new "data" onto the screen; 3. an
> optional pop-up display showing (x,y) coordinates of object or data knob
> being dragged.
>
> Incidentally: I just noticed that the IEM slider object (and proabbly
> other EM GUIs) spits out a number when clicked upon, even if not
> dragged.  Is this desirable behavior?  It caught me out buit perhaps
> other users are actually wanting to be able to click on a control to
> repeat its value.  Hmm..
>
> cheers
>
> Miller
>
>
>
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] release April?

[Antoine Rousseau]

@miller:

> I just noticed that the IEM slider object spits out a number when clicked
> upon


This has always been the case as far as i know (and I've just tested on
0.43.0 and it was already true).
I don't think this should change...


Le mar. 12 mars 2024 à 14:34, Alexandre Torres Porres  a
écrit :

> I replied without seeing other messages, sorry, in a rush here :)
>
> Em ter., 12 de mar. de 2024 às 10:20, Alexandre Torres Porres <
> por...@gmail.com> escreveu:
>
>> Some PRs for that
>>
>> https://github.com/pure-data/pure-data/pull/2059
>> https://github.com/pure-data/pure-data/pull/1978
>> https://github.com/pure-data/pure-data/pull/2049
>> https://github.com/pure-data/pure-data/pull/2052
>> https://github.com/pure-data/pure-data/pull/2110
>>
>
> so, besides multichannel stuff from christof in the middle, last one is
> adding MC secondary signals to clip~ and the 1st is to draw a thicker MC
> connection line
>
>
>
>> In general, instead of a very dense 2-week merge window twice a year, it
>> would great to merge PRs on a mere regular basis. Not only would it
>> cause less stress, it would also give us more time to find bugs before
>> the actual release. That's just my personal opinion, of course.
>>
>
> +1 :)
>
> may I ask if you're finally retired from classes at UCSD by the way Miller
> ;)
>
> cheers
>
>>
>> ---
>>
>> A few things from my side:
>>
>> 1. Please consider my scheduler improvements:
>> https://github.com/pure-data/pure-data/pull/1756
>>
>> I have been using this for 1 1/2 years now, both in my daily patching
>> and in big concerts (including an opera production!), and I can't live
>> without it anymore. It would be nice if other people could enjoy these
>> improvements as well. Also, I wouldn't have to hand out custom Pd
>> versions to my performers anymore :)
>>
>> ---
>>
>> 2. There are quite a few missing multichannel features!
>>
>> Here are my multichannel PRs:
>>
>> * MC support for [print~], [snapshot~] and [sig~]:
>> https://github.com/pure-data/pure-data/pull/1978
>>
>> * MC support for [readsf~] and [writesf~]:
>> https://github.com/pure-data/pure-data/pull/2052
>>
>> * MC support for [delwrite~], [delread~] and [delread4~]:
>> https://github.com/pure-data/pure-data/pull/2049
>>
>> * allow to change the number of tables/channels in table DSP objects:
>> https://github.com/pure-data/pure-data/pull/2058
>>
>> * signal comparison operators (finally!) with multichannel support:
>> https://github.com/pure-data/pure-data/pull/2054
>>
>> The [snake~] object is also missing a few crucial features, most
>> importantly:
>>
>> * query the number of channels in a MC signal, e.g. [snake~ count]
>>
>> * combine several MC signals into a single MC signal, e.g. [snake~
>> join], or extend [snake~ in to accept multichannel signals
>>
>> * split a MC signal into several MC signals resp. get a subset of
>> channels, e.g. [snake~ split] resp. [snake~ get]
>>
>> * sum a MC signal, e.g. [snake~ sum]
>>
>> People are already implementing these as externals, but these features
>> seem so basic that they really should be part of Pd vanilla IMO.
>>
>> For reference, here's the discussion:
>> https://github.com/pure-data/pure-data/issues/1996
>>
>> ---
>>
>> A few other things I really want to see eventually (not necessarily for
>> this release):
>>
>> * more clone improvements:
>> https://github.com/pure-data/pure-data/pull/2053
>>
>> * "goprect" method: https://github.com/pure-data/pure-data/pull/627.
>> Solves a real issue and lying around for 5 years now.
>>
>> * namespace constructors for all external objects:
>> https://github.com/pure-data/pure-data/pull/630. Solves a real issue and
>> lying around for 5 years.
>>
>> Cheers,
>>
>> Christof
>>
>> PS: here is a full list of my open PRs, in case anyone is interested:
>>
>> https://github.com/pure-data/pure-data/pulls/Spacechild1?page=1=is%3Aopen+is%3Apr+author%3ASpacechild1
>>
>> On 12.03.2024 08:47, Miller Puckette wrote:
>> > To Pd dev -
>> >
>> > I'm thinking of making a release mid April (assuming things go well)
>> > and so I should probably call for a freeze late March.  As usual I
>> > plan to merge in "devel" and "Documentation" - in fact I should do a
>> > first merge rather soon, assuming things are in a good state for
>> merging.
>> >
>> > I'm planning to add a couple of features: 1. message to Pd to toggle
>> > between GUI and no-GUI -- perhaps with a way to reset the GUI startup
>> > command -- so that if you have a headless installation that's doing
>> > something funny you can pop it open and look; and 2. improvements to
>> > the "pointer" object to make it easier to get around data structures,
>> > and possibly a menu extension for dragging new "data" onto the screen;
>> > 3. an optional pop-up display showing (x,y) coordinates of object or
>> > data knob being dragged.
>> >
>> > Incidentally: I just noticed that the IEM slider object (and proabbly
>> > other EM GUIs) spits out a number when clicked upon, even if not
>> > 

Re: [PD-dev] time for a quick bugfix update?

[Antoine Rousseau]

+1

Le sam. 21 oct. 2023 à 18:57, Alexandre Torres Porres  a
écrit :

> Hi, we have an issue with the latest macOS, see
> https://github.com/pure-data/pure-data/issues/2105
>
> It seems an upgrade of tcl/tk is required and it would be worth a bugfix
> release as I see it. What do people say?
>
> cheers
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] double precision pd?

[Antoine Rousseau]

>
> My trouble with Pd64 is that it will get listed next to Pd in almost any
> package manager and may be many people
> opt Pd64 (thinking that is the one for 64bit cpus)


I think almost all (recent) package managers no longer offer 32bit-CPU
packages?...

Antoine



Le mer. 7 juin 2023 à 13:08, Lucas Cordiviola  a
écrit :

> > Funnily, my personal feeling is the opposite :-)
> > I feel that Pd64 clearly describes Pd working with 64 bit data.
>
>
> I myself don't have any trouble with whatever name we use as I know
> perfectly well the situation. My trouble with Pd64 is that it will get
> listed next to Pd in almost any package manager and may be many people
> opt Pd64 (thinking that is the one for 64bit cpus)
>
> Pd2 is also a good one.
>
>
> --
>
> Mensaje telepatico asistido por maquinas.
>
> On 07/06/2023 07:55, Antoine Rousseau wrote:
> > Le mer. 7 juin 2023 à 10:47, Lucas Cordiviola 
> > a écrit :
> >
> > For me pd64 gives more chances of confusion than pdd or pdpd.
> >
> >  (...)
> >
> > Starting with a new name of the app seems the most sane.
> >
> >
> > Funnily, my personal feeling is the opposite :-)
> > I feel that Pd64 clearly describes Pd working with 64 bit data.
> > I think that confusion with 64 bit architectures will become less
> > present, since nowadays most (all?) major platforms are based on 64
> > bit CPUs. So "64 bit" is just a particular taste of CPUs, as in x86_64
> > or arm64, which has no direct impact from the user's point of view. If
> > you want to work with 64bit-wide data on a 32bit PPC, you just need
> > Pd64-PPC32, on arm64 it will be Pd64-arm64.
> >
> > To me, "pdd" or "pdpd" really sound like different apps, which I find
> > a bit strange (it's actually the same app, only different options).
> > I quite like Pd² or even Pd2, though.
> >
> >
> > .
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] double precision pd?

[Antoine Rousseau]

Le mer. 7 juin 2023 à 10:47, Lucas Cordiviola  a
écrit :

> For me pd64 gives more chances of confusion than pdd or pdpd.
>
 (...)

> Starting with a new name of the app seems the most sane.
>

Funnily, my personal feeling is the opposite :-)
I feel that Pd64 clearly describes Pd working with 64 bit data.
I think that confusion with 64 bit architectures will become less present,
since nowadays most (all?) major platforms are based on 64 bit CPUs. So "64
bit" is just a particular taste of CPUs, as in x86_64 or arm64, which has
no direct impact from the user's point of view. If you want to work with
64bit-wide data on a 32bit PPC, you just need Pd64-PPC32, on arm64 it will
be Pd64-arm64.

To me, "pdd" or "pdpd" really sound like different apps, which I find a bit
strange (it's actually the same app, only different options).
I quite like Pd² or even Pd2, though.


.
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] bug in double click event in a GUI in a GOP?

[Antoine Rousseau]

Hi Alex,

This has already been reported in
https://github.com/pure-data/pure-data/issues/1661.
It turns out that it won't be easy to fix, even if it should be possible.



Le sam. 8 avr. 2023 à 00:18, Alexandre Torres Porres  a
écrit :

> Hi, I am designing a knob GUI and it has a feature for double click where
> it goes to the mid position (or some other setting) when you do it. This is
> quite cool and I'm happy with it.
>
> Then I was testing it inside an abstraction, as I wanna use this to design
> modular inspired abstractions and to my frustration it doesn't work.
> Somehow the 'double click' event that we get from 'w_clickfn' in
> 't_widgetbehavior'...
>
> In Vanilla, double click in a GUI (when in run mode) is only possible for
> gui boxes (atom/symbol/list), which lets us select the contents of the box.
> I haven't looked at its code, but I can see it is also not possible to
> double click it in a GOP, so it might be the same thing.
>
> Well, is this intentional? Is this a bug? Can I ask to change this?
>
> I would really like to be able to write GUIs that make use of double
> clicking, not being able to do so seems like a very weird and arbitrary
> restriction.
>
> Thanks
> Cheers
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] multichannel signals, preliminary support

[Antoine Rousseau]

> naming of [pack~]/[unpack~]

Maybe they also could be called:
[group~]/[ungroup~] ?
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pack~/unpack~ (was Re: multichannel signals, preliminary support)

[Antoine Rousseau]

I think the proposal join~/split~ is the one I prefer.
It follows quite well the naming of other pairs like throw~/catch~ or
send~/receive~.
Just a personal feeling...

Antoine


Le mar. 24 janv. 2023 à 08:25, Matt Barber  a écrit :

> I was also going to suggest snake~ as the accepted hardware metaphor. I
> think it would maybe be snake~ and breakout~ if taken literally.
>
> In order to make in/out clear, it might be insnake~ outsnake~
>
>
> bundle~ unbundle~ would also be an intuitive choice.
>
> Whatever it ends up being, I think there definitely needs to be a visual
> clue that the connection is multichannel, and maybe to reveal the number of
> channels on hover in edit mode for clarity and debugging (especially in
> deep patch nesting)
>
> On Mon, Jan 23, 2023, 4:54 PM Alexandre Torres Porres 
> wrote:
>
>> I find snake~ and unsafe~ a bit weird but amusing, I kinda like idea of
>> typing that object name and read it in a patch
>>
>> On Mon, 23 Jan 2023 at 18:49 Miller Puckette  wrote:
>>
>>> How about "snake~ in" and "snake~ out" ... assuming a "snake" is easily
>>> enough understood as a multichannel audio cable?
>>>
>>> Or tosnake~ / fromsnake~ or even snake~ and unsnake~ ?
>>>
>>> cheers
>>> M
>>>
>>> On Mon, Jan 23, 2023 at 09:02:33AM -0300, Alexandre Torres Porres wrote:
>>> > I actually do like pack~/unpack~ a lot, because they have control
>>> > counterparts and also MAX uses something similar but prepends 'mc.' to
>>> it,
>>> > so [mc.pack~] and [mc.unpack~] are exactly what [pack~] and [unpack~]
>>> do!
>>> >
>>> > On the other hand, if we really want to avoid this collision badly,
>>> maybe
>>> > we could use a similar convention to specify an object that is
>>> multichannel
>>> > aware, something quite new in the pd world. I'm not saying we should
>>> use
>>> > the same 'mc.' convention. I know using "." is not much common in the
>>> Pd
>>> > world, but in ELSE I use it and have plans to add many multichannel
>>> aware
>>> > externals that would make things simpler and while we don't have our
>>> > [clone] solution for internal and external objects, like a muti channel
>>> > [dac~] object called [dac.mc~]. I like it better that the mc comes
>>> later as
>>> > objects would be alphabetically next to their multichannel version.
>>> This
>>> > would also prevent people from thinking it's an external from Cyclone
>>> that
>>> > mimics the original.
>>> >
>>> >
>>> > So... what about [pack.mc~] and [unpack.mc~]?
>>> >
>>> > maybe just [packmc~] and [unpackmc~] as well... but I like "."
>>> >
>>> > cheers
>>> >
>>> > Em seg., 23 de jan. de 2023 às 06:38, Roman Haefeli <
>>> reduz...@gmail.com>
>>> > escreveu:
>>> >
>>> > > On Mon, 2023-01-23 at 08:40 +0100, IOhannes m zmoelnig wrote:
>>> > > >
>>> > > > i would prefer this.
>>> > > > howe about the [split~]/[merge~] pair suggested by Jean-Yves?
>>> > >
>>> > > I think those are more descriptive names, regardless of the name
>>> > > collision problem.
>>> > >
>>> > > + 1
>>> > >
>>> > > > in retrospect i wouldn't have named the zexy objects like i did,
>>> but
>>> > > > i
>>> > > > was young and needed the money.
>>> > >
>>> > > I don't think 'pack~' and 'unpack~' fit any less to what zexy's
>>> objects
>>> > > do. Like their non-tilde counterparts, they pack to lists und unpack
>>> > > from lists. I think those names are quite good.
>>> > >
>>> > > Roman
>>> > >
>>> > > ___
>>> > > Pd-dev mailing list
>>> > > Pd-dev@lists.iem.at
>>> > >
>>> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!Mih3wA!FiLq_YDUBYda6b---jre9DEKXbAOKoHQN8RElivzd1cjtYcN1BN4iAg_OvfczMaP7N7QraScCw$
>>> > >
>>>
>>> > ___
>>> > Pd-dev mailing list
>>> > Pd-dev@lists.iem.at
>>> >
>>> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!Mih3wA!FiLq_YDUBYda6b---jre9DEKXbAOKoHQN8RElivzd1cjtYcN1BN4iAg_OvfczMaP7N7QraScCw$
>>>
>>> ___
>> Pd-dev mailing list
>> Pd-dev@lists.iem.at
>> https://lists.puredata.info/listinfo/pd-dev
>>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] release time?

[Antoine Rousseau]

>
> we should retire the public iemgui API
>

does this mean that mknob (or iemgui library) would have to be entirely
rewritten, by copying/adapting the entire iemgui API to mkob source tree?

not caring about ABI breakage
>

the ABI compatibility is already broken IIUC ;-)

GUI objects aren't that common for Pd, unfortunately
>

obviously... there would be many more with a better (and more stable...)
GUI system. We all feel that we need to move forward.
@IOhannes is it for this reason that you want to retract the iemgui API? To
have freer hands when modifying the GUI code?

I totally understand this reason; however, maybe we can wait here, since
it's unlikely that someone starts a new GUI project on the current
codebase, before we switch to a better system...
I wouldn't want to have to rewrite the mknob, which would be needed by
someone (not me actually...) who would need Pd 0.54 at the same time
We could simply discourage new developers from using the API, maybe
signaling it's about to be deprecated.

Antoine


Le lun. 28 nov. 2022 à 03:48, Alexandre Torres Porres  a
écrit :

>
>
> Em dom., 27 de nov. de 2022 às 23:33, Alexandre Torres Porres <
> por...@gmail.com> escreveu:
>
>> We can investigate.
>>
>
> besides moonlib's knob, the knob from 'flatgui' also uses it.
>
> I also found objects in "iemgui" that uses it, like [cube_sphere] (I guess
> "IEM" can easily take care of this one hehe).
>
> These are all the ones found in Pd Extended. I don't remember or know of
> any new compiled GUIs popping up since its demise that would use this. The
> ones from ELSE don't use it, the ones from CEAMMC don't either.
>
> Again, GUI objects aren't that common for Pd, unfortunately.
>
> cheers
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] release pd 0.52 update?

[Antoine Rousseau]

note that #1635 has conflicts; I think it has been made obsolete by the
recent rework of the interface to GUI (probably should be closed).

Antoine



Le ven. 14 oct. 2022 à 06:23, Alexandre Torres Porres  a
écrit :

>
>
> Em qui., 13 de out. de 2022 às 23:26, Miller Puckette via Pd-dev <
> pd-dev@lists.iem.at> escreveu:
>
>> Are there other updates that need to make
>> their way into Pd 0.52-1?
>>
>
> btw, I was checking, current version is 0.52-2, so the bugfix update would
> be 0.52-3, right?
>
> cheers
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] tilde object rework ideas

[Antoine Rousseau]

Sorry forget it, "frames" actually corresponds with the comment
 /* number of points in each channel */".

Le ven. 2 sept. 2022 à 10:55, Antoine Rousseau  a
écrit :

> > probably "s_length" might be called "s_frames"
>
> I'm not sure about that: in many APIs the word "frame" means one
> "multi-channel sample", e.g 2 samples for a stereo stream.
>
>
>
> Le ven. 2 sept. 2022 à 09:36, IOhannes m zmoelnig  a
> écrit :
>
>> On 9/2/22 01:00, Christof Ressi wrote:
>> > Hi Miller,
>> >
>> > this sounds great! First-class multi-channel support would be a real
>> > game changer.
>>
>>
>> yes. that would be so cool!
>>
>>
>> >> typedef struct _signal
>> >> {
>> >>  int s_n;/* *TOTAL* number of points in the array */
>> >>  t_sample *s_vec;/* the array */
>> >>  t_float s_sr;   /* *TOTAL* samples per second */
>> [...]
>> >>  t_float s_rate; /* sample rate */
>> >>  int s_length;   /* number of points in each channel */
>> >>  int s_nchans;   /* number of channels */
>> >>  int s_overlap;  /* number of times each sample will appear */
>> >> }
>> > 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
>> externals would automatically process *all* channels.
>>
>> that's nice if the external does not do any delays or so (as they would
>> automatically become multi-channel aware), but not so nice if they *do*
>> things in the time domain (as there would be weird cross-talk between
>> the channels).
>>
>> i'm not favouring any of the two approaches, just wanted to point their
>> differences.
>>
>> i somewhat agree with christof's implication, that it's probably best to
>> not have redundant data in the struct.
>> - 's_n = s_nchans * s_length' (or 's_totalsamples = s_nchans * s_n')
>> - 's_sr = s_rate * s_overlap * s_nchans'
>>
>> (my issue being, that with redundancy it's more likely to have
>> inconsistent data; what if the struct says 's_n = 128; s_nchans = 3;
>> s_length = 1024'?)
>>
>> apart from that:
>> probably "s_length" might be called "s_frames" as this seems to be the
>> less ambiguous term.
>>
>> and i would personally prefer "s_samplerate" and "s_channels".
>> that would make for an easy distinction: the abbreviated names "s_n" and
>> "s_sr" are the convoluted ones, whereas the long names have the data
>> you'd expect.
>>
>>
>>
>> > channel and ignore the rest. Newer multi-channel-aware externals, on
>> the
>> > other hand, may use all the channels.
>> >
>> > I also think that DSP objects would need a new API method to create
>> > multi-channel /outputs/. The general idea is that the /input /channel
>> > counts are taken from upstream, but the /output /channel counts are
>> > specified by the object and passed downstream. (There might be objects
>> > where input and output channel count differs; any kind of
>> > merger/splitter/mixer objects comes to my mind.)
>>
>> +1
>>
>> vgmasdrf
>> IOhannes
>> ___
>> Pd-dev mailing list
>> Pd-dev@lists.iem.at
>> https://lists.puredata.info/listinfo/pd-dev
>>
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] tilde object rework ideas

[Antoine Rousseau]

> probably "s_length" might be called "s_frames"

I'm not sure about that: in many APIs the word "frame" means one
"multi-channel sample", e.g 2 samples for a stereo stream.



Le ven. 2 sept. 2022 à 09:36, IOhannes m zmoelnig  a
écrit :

> On 9/2/22 01:00, Christof Ressi wrote:
> > Hi Miller,
> >
> > this sounds great! First-class multi-channel support would be a real
> > game changer.
>
>
> yes. that would be so cool!
>
>
> >> typedef struct _signal
> >> {
> >>  int s_n;/* *TOTAL* number of points in the array */
> >>  t_sample *s_vec;/* the array */
> >>  t_float s_sr;   /* *TOTAL* samples per second */
> [...]
> >>  t_float s_rate; /* sample rate */
> >>  int s_length;   /* number of points in each channel */
> >>  int s_nchans;   /* number of channels */
> >>  int s_overlap;  /* number of times each sample will appear */
> >> }
> > 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
> externals would automatically process *all* channels.
>
> that's nice if the external does not do any delays or so (as they would
> automatically become multi-channel aware), but not so nice if they *do*
> things in the time domain (as there would be weird cross-talk between
> the channels).
>
> i'm not favouring any of the two approaches, just wanted to point their
> differences.
>
> i somewhat agree with christof's implication, that it's probably best to
> not have redundant data in the struct.
> - 's_n = s_nchans * s_length' (or 's_totalsamples = s_nchans * s_n')
> - 's_sr = s_rate * s_overlap * s_nchans'
>
> (my issue being, that with redundancy it's more likely to have
> inconsistent data; what if the struct says 's_n = 128; s_nchans = 3;
> s_length = 1024'?)
>
> apart from that:
> probably "s_length" might be called "s_frames" as this seems to be the
> less ambiguous term.
>
> and i would personally prefer "s_samplerate" and "s_channels".
> that would make for an easy distinction: the abbreviated names "s_n" and
> "s_sr" are the convoluted ones, whereas the long names have the data
> you'd expect.
>
>
>
> > channel and ignore the rest. Newer multi-channel-aware externals, on the
> > other hand, may use all the channels.
> >
> > I also think that DSP objects would need a new API method to create
> > multi-channel /outputs/. The general idea is that the /input /channel
> > counts are taken from upstream, but the /output /channel counts are
> > specified by the object and passed downstream. (There might be objects
> > where input and output channel count differs; any kind of
> > merger/splitter/mixer objects comes to my mind.)
>
> +1
>
> vgmasdrf
> IOhannes
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] PDINSTANCE for Pd (was Re: call for discussion double-precision file extension)

[Antoine Rousseau]

(sorry, too long mail polling, your answer came after my previous one)

cases where an external might want to behave differently depending on
> whether PDINSTANCE is defined or not
>

yes you're right... I remember I helped to fix readsf~/writesf~ for
multi-instance / multi-thread context, by adding  *pd_setinstance() *in the
helper threads.
so I agree with your conclusion. Things will have to be prepared
carefully...

Le lun. 4 avr. 2022 à 15:49, Antoine Rousseau  a écrit :

> ABI break for multi-instance libpd
>>
>
> only externals already compiled for multi-instance would have to be
> recompiled, I think.
> And it wouldn't allow current externals to be used in a multi-instance
> context.
>
> But it would allow a Pd compiled with PDINSTANCE, or a single-instance
> libpd app compiled with PDINSTANCE to load current externals (compiled
> without PDINSTANCE).
>
> Antoine
>
>
>
> Le lun. 4 avr. 2022 à 15:00, Christof Ressi  a
> écrit :
>
>> I was thinking to a way for the transition: we could:
>> - change the t_pdinstance pd_s_* fields to pointers (and adapt the s_*
>> replacement  macros accordingly),
>> - export "hidden" globals s_*
>> - initialize pd_maininstance pd_s_* fields to the global versions.
>>
>> Yes, this would work. Of course, it would be an ABI break for
>> multi-instance libpd, but I think it would be justified. I guess libpd
>> users rarely rely on pre-build externals, and even if they do, I think it's
>> ok to ask them to recompile.
>>
>> We should probably also put the global s_* symbols in a deprecation macro
>> that tells external authors to use gensym() instead.
>>
>> Christof
>> On 04.04.2022 13:55, Antoine Rousseau wrote:
>>
>> I very much agree that in the future Pd (and externals) could be always
>> compiled with PDINSTANCE.
>>
>> I was thinking to a way for the transition: we could:
>> - change the t_pdinstance pd_s_* fields to pointers (and adapt the s_*
>> replacement  macros accordingly),
>> - export "hidden" globals s_*
>> - initialize pd_maininstance pd_s_* fields to the global versions.
>>
>> CURRENT:
>> /* m_pd.h */
>> struct _pdinstance
>> {
>> t_symbol  pd_s_float;
>> }
>> #define s_float (pd_this->pd_s_float)
>>
>> /* m_class.c */
>> t_pdinstance *pdinstance_init(t_pdinstance *x)
>> {
>> dogensym("float", >pd_s_float,x);
>> }
>>
>> PROPOSAL:
>> /* m_pd.h */
>> struct _pdinstance
>> {
>> t_symbol  *pd_s_float;
>> }
>> #define s_float (*(pd_this->pd_s_float))
>>
>> /* m_class.c */
>> #undef s_float
>> t_symbol s_float;
>> t_pdinstance *pdinstance_init(t_pdinstance *x)
>> {
>> if(x != _maininstance) x->pd_s_float = gensym("float");
>> else {
>> dogensym("float", _float,x);
>> x->pd_s_float = _float;
>> }
>>
>> What do you think?
>>
>> I've tried this (in libpd context) almost successfully, but I've
>> encountered a problem: the s_float as seen from an app linked to libpd
>> seems to be uninitialized.
>> I've tried something simpler:
>> /* m_class.c */
>> float myfloat = 10.0;
>> t_pdinstance *pdinstance_init(t_pdinstance *x)
>> {
>> myfloat = 20.0;
>> printf("pdinstance_init::myfloat: %f\n", myfloat);
>> }
>>
>> /* pdtest.c */
>> extern float 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 why pdtest doesn't see the updated value?
>>
>> Le mer. 30 mars 2022 à 23:51, Christof Ressi  a
>> écrit :
>>
>>> 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 main Pd instance. But in this case I don't really see a
>>> solution...
>>>
>>> On 30.03.2022 18:07, IOhannes m zmoelnig wrote:
>>> >
>>> > On 3/30/22 17

Re: [PD-dev] PDINSTANCE for Pd (was Re: call for discussion double-precision file extension)

[Antoine Rousseau]

>
> ABI break for multi-instance libpd
>

only externals already compiled for multi-instance would have to be
recompiled, I think.
And it wouldn't allow current externals to be used in a multi-instance
context.

But it would allow a Pd compiled with PDINSTANCE, or a single-instance
libpd app compiled with PDINSTANCE to load current externals (compiled
without PDINSTANCE).

Antoine



Le lun. 4 avr. 2022 à 15:00, Christof Ressi  a
écrit :

> I was thinking to a way for the transition: we could:
> - change the t_pdinstance pd_s_* fields to pointers (and adapt the s_*
> replacement  macros accordingly),
> - export "hidden" globals s_*
> - initialize pd_maininstance pd_s_* fields to the global versions.
>
> Yes, this would work. Of course, it would be an ABI break for
> multi-instance libpd, but I think it would be justified. I guess libpd
> users rarely rely on pre-build externals, and even if they do, I think it's
> ok to ask them to recompile.
>
> We should probably also put the global s_* symbols in a deprecation macro
> that tells external authors to use gensym() instead.
>
> Christof
> On 04.04.2022 13:55, Antoine Rousseau wrote:
>
> I very much agree that in the future Pd (and externals) could be always
> compiled with PDINSTANCE.
>
> I was thinking to a way for the transition: we could:
> - change the t_pdinstance pd_s_* fields to pointers (and adapt the s_*
> replacement  macros accordingly),
> - export "hidden" globals s_*
> - initialize pd_maininstance pd_s_* fields to the global versions.
>
> CURRENT:
> /* m_pd.h */
> struct _pdinstance
> {
> t_symbol  pd_s_float;
> }
> #define s_float (pd_this->pd_s_float)
>
> /* m_class.c */
> t_pdinstance *pdinstance_init(t_pdinstance *x)
> {
> dogensym("float", >pd_s_float,x);
> }
>
> PROPOSAL:
> /* m_pd.h */
> struct _pdinstance
> {
> t_symbol  *pd_s_float;
> }
> #define s_float (*(pd_this->pd_s_float))
>
> /* m_class.c */
> #undef s_float
> t_symbol s_float;
> t_pdinstance *pdinstance_init(t_pdinstance *x)
> {
> if(x != _maininstance) x->pd_s_float = gensym("float");
> else {
> dogensym("float", _float,x);
> x->pd_s_float = _float;
> }
>
> What do you think?
>
> I've tried this (in libpd context) almost successfully, but I've
> encountered a problem: the s_float as seen from an app linked to libpd
> seems to be uninitialized.
> I've tried something simpler:
> /* m_class.c */
> float myfloat = 10.0;
> t_pdinstance *pdinstance_init(t_pdinstance *x)
> {
> myfloat = 20.0;
> printf("pdinstance_init::myfloat: %f\n", myfloat);
> }
>
> /* pdtest.c */
> extern float 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 why pdtest doesn't see the updated value?
>
> Le mer. 30 mars 2022 à 23:51, Christof Ressi  a
> écrit :
>
>> 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 main Pd instance. But in this case I don't really see a
>> solution...
>>
>> On 30.03.2022 18:07, IOhannes m zmoelnig wrote:
>> >
>> > On 3/30/22 17:45, Dan Wilcox wrote:
>> >> I lean much more on the side that PDINSTANCE is a low-level, per
>> >> project compile option and not general-purpose. If you are using
>> >> libpd, then your environment is a bit more custom anyway.
>> >
>> > i wonder what the penalty would be to turn on PDINSTANCE on Pd?
>> >
>> >
>> > obviously a problem with externals, but maybe we can come up with some
>> > clever hack (under the assumption, that Pd (the app) only runs a
>> > single instance, even if compiled with multi-instance support) to use
>> > legacy externals - if that is even possible.
>> >
>> > apart from that?
>> >
>> > fgadrms
>> > IOhannes
>> >
>> > ___
>> > Pd-dev mailing list
>> > Pd-dev@lists.iem.at
>> > https://lists.puredata.info/listinfo/pd-dev
>>
>>
>>
>> ___
>> Pd-dev mailing list
>> Pd-dev@lists.iem.at
>> https://lists.puredata.info/listinfo/pd-dev
>>
>
> ___
> Pd-dev mailing 
> listpd-...@lists.iem.athttps://lists.puredata.info/listinfo/pd-dev
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] PDINSTANCE for Pd (was Re: call for discussion double-precision file extension)

[Antoine Rousseau]

I very much agree that in the future Pd (and externals) could be always
compiled with PDINSTANCE.

I was thinking to a way for the transition: we could:
- change the t_pdinstance pd_s_* fields to pointers (and adapt the s_*
replacement  macros accordingly),
- export "hidden" globals s_*
- initialize pd_maininstance pd_s_* fields to the global versions.

CURRENT:
/* m_pd.h */
struct _pdinstance
{
t_symbol  pd_s_float;
}
#define s_float (pd_this->pd_s_float)

/* m_class.c */
t_pdinstance *pdinstance_init(t_pdinstance *x)
{
dogensym("float", >pd_s_float,x);
}

PROPOSAL:
/* m_pd.h */
struct _pdinstance
{
t_symbol  *pd_s_float;
}
#define s_float (*(pd_this->pd_s_float))

/* m_class.c */
#undef s_float
t_symbol s_float;
t_pdinstance *pdinstance_init(t_pdinstance *x)
{
if(x != _maininstance) x->pd_s_float = gensym("float");
else {
dogensym("float", _float,x);
x->pd_s_float = _float;
}

What do you think?

I've tried this (in libpd context) almost successfully, but I've
encountered a problem: the s_float as seen from an app linked to libpd
seems to be uninitialized.
I've tried something simpler:
/* m_class.c */
float myfloat = 10.0;
t_pdinstance *pdinstance_init(t_pdinstance *x)
{
myfloat = 20.0;
printf("pdinstance_init::myfloat: %f\n", myfloat);
}

/* pdtest.c */
extern float 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 why pdtest doesn't see the updated value?

Le mer. 30 mars 2022 à 23:51, Christof Ressi  a
écrit :

> 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 main Pd instance. But in this case I don't really see a
> solution...
>
> On 30.03.2022 18:07, IOhannes m zmoelnig wrote:
> >
> > On 3/30/22 17:45, Dan Wilcox wrote:
> >> I lean much more on the side that PDINSTANCE is a low-level, per
> >> project compile option and not general-purpose. If you are using
> >> libpd, then your environment is a bit more custom anyway.
> >
> > i wonder what the penalty would be to turn on PDINSTANCE on Pd?
> >
> >
> > obviously a problem with externals, but maybe we can come up with some
> > clever hack (under the assumption, that Pd (the app) only runs a
> > single instance, even if compiled with multi-instance support) to use
> > legacy externals - if that is even possible.
> >
> > apart from that?
> >
> > fgadrms
> > IOhannes
> >
> > ___
> > Pd-dev mailing list
> > Pd-dev@lists.iem.at
> > https://lists.puredata.info/listinfo/pd-dev
>
>
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Why not use portaudio per default?

[Antoine Rousseau]

>
> we build the sources ourselves, as you have noted, it probably
> makes sense to keep them in our repo as well
>

[submodules]  make problems when using 'git archive'
>

submodules do not allow for patching the vendored sources
>

Maybe it's the right use case for "git subtree"?
(see e.g https://manpages.debian.org/testing/git-man/git-subtree.1.en.html)
I never used it myself though...

Antoine



Le sam. 22 janv. 2022 à 19:43, Dan Wilcox  a écrit :

> It's actually relatively easy, but very verbose since running configure
> then runs the dependent lib configures as well. You just have to point the
> configure script to the subdirectory with another configure script.
>
> I have a couple projects which use autotools and rely on a couple custom
> libraries which also use autotools. You just pass the subdirectories via
> AC_CONFIG_SUBDIRS:
> https://github.com/danomatika/joyosc/blob/master/configure.ac#L85
>
> But in the end, I plan to simplify this layout and remove the need for
> this arrangement in the future.
>
> On Jan 22, 2022, at 6:57 PM, pd-dev-requ...@lists.iem.at wrote:
>
> Since we build the sources ourselves, as you have noted, it probably
> makes sense to keep them in our repo as well. I don't even know how to
> properly integrate an automake project...
>
>
> 
> Dan Wilcox
> @danomatika 
> danomatika.com
> robotcowboy.com
>
>
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] fixed the Pd_documentation link in http://puredata.info/docs/manuals/pd/pd-documentation

[Antoine Rousseau]

>
> BTW, this page (on puredata.info) is outdated. I'm not sure of the
>> correct way to update it to the latest (github) version.
>>
>
> this is the version you need to link to =>
> http://msp.ucsd.edu/Pd_documentation/index.htm
>

That's what I did; but what I'm saying is that the HTML manual that you can
read in the http://puredata.info/docs/manuals/pd/pd-documentation page is
outdated (see Chapter 4, it's still called "writing Pd objects in C"
<http://puredata.info/docs/manuals/pd/x4.htm>).
<http://puredata.info/docs/manuals/pd/x4.htm>


Also, in the latest (github) version (and the Miller's site version) of
>> index.htm, the link is
>> "http://msp.ucsd.edu/software.html;, but that seems wrong (as this
>> points to the root of Miller's "software" page, not the "latest version of
>> this [documentation] page".
>>
>
> where exactly are you talking about?
>

The complete sentence is :
"The latest version of this page can be found at:
http://msp.ucsd.edu/software.html;
But http://msp.ucsd.edu/software.html is not the "latest version of this
page", but Miller's "Software" page instead (from where you can find the HTML
documentation for Pd <http://msp.ucsd.edu/Pd_documentation/index.htm>).
So I think either the link or the sentence itself should be changed.




Le jeu. 9 déc. 2021 à 15:19, Alexandre Torres Porres  a
écrit :

>
>
> Em qui., 9 de dez. de 2021 às 09:31, Antoine Rousseau 
> escreveu:
>
>>
>> BTW, this page (on puredata.info) is outdated. I'm not sure of the
>> correct way to update it to the latest (github) version.
>>
>
> this is the version you need to link to =>
> http://msp.ucsd.edu/Pd_documentation/index.htm
>
>
>
>> Also, in the latest (github) version (and the Miller's site version) of
>> index.htm, the link is
>> "http://msp.ucsd.edu/software.html;, but that seems wrong (as this
>> points to the root of Miller's "software" page, not the "latest version of
>> this [documentation] page".
>>
>
> where exactly are you talking about?
>
> cheers
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] fixed the Pd_documentation link in http://puredata.info/docs/manuals/pd/pd-documentation

[Antoine Rousseau]

FYI, I've fixed the link to Miller's site that appears at the top of
http://puredata.info/docs/manuals/pd/pd-documentation ; it was using a
"www." prefix that didn't work. I've set it to "
http://msp.ucsd.edu/Pd_documentation/index.htm;, which is how my browser
finally resolves it.

BTW, this page (on puredata.info) is outdated. I'm not sure of the correct
way to update it to the latest (github) version.

Also, in the latest (github) version (and the Miller's site version) of
index.htm, the link is
"http://msp.ucsd.edu/software.html;, but that seems wrong (as this points
to the root of Miller's "software" page, not the "latest version of this
[documentation] page".

Antoine
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] another file path question for sp4d

[Antoine Rousseau]

the functions "canvas_open()" and "canvas_makefilename()" can do all this
for you, in the same way as other data files (texts, arrays, wavs...) are
opened.

- do *not* traverse through all directories on the Pd search paths
>

why not?  Is it a problem if it finds "scm/foo.scm" somewhere else? I say
that because "canvas_open()" and "canvas_makefilename()" WILL traverse Pd
search paths...


Antoine



Le ven. 8 oct. 2021 à 17:01, Iain Duncan  a
écrit :

> Hi folks, I want to solicit opinions from the broader Pd dev community
> before figuring out how to fix this bug report from Alex:
> https://github.com/iainctduncan/scheme-for-pd/issues/15
>
> His point was that a relative path didn't do what he expected, situation
> - an s4pd object created as "sp4d scm/my-file.scm"
>
> So this is what I think should happen for file searching, but will change
> my mind if it is not in accordance with what users would expect. The
> handling rules will be the same whether from a a "read {file}" message or
> an arg to the object:
>
> Proposed Rules:
> - absolute paths - opened
> - single file name paths:
>- first look in the canvas directory
>- then search all Pd paths
> - relative path names (i.e. "s4pd scm/foo.scm"):
>   - search in the canvas directory
>   - do *not* traverse through all directories on the Pd search paths
>
> Does that sound right? Or would the expectation be that it would search
> for scm/foo.js on all the search paths?
>
> Related, should it know how to do the right thing to convert unix style
> paths on windows?
>
> Please feel free to comment here or on the github ticket.
>
> thanks
> iain
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] "extra" folder is not showing its content in Pd's browser.

[Antoine Rousseau]

>
> I'm preparing a PR.
>
done: https://github.com/pure-data/pure-data/pull/1372


Le mer. 1 sept. 2021 à 13:30, Antoine Rousseau  a
écrit :

>
> the problem is that s_main::sys_main() first calls
> s_inter::sys_startgui(), which calls s_inter::sys_do_startgui() which then
> calls s_path::sys_set_extrapath() (send extrapath to GUI),
> before it calls s_main::sys_afterargparse() which calls
> s_path::sys_setextrapath (init extrapath for the OS).
>
> I suggest just calling sys_afterargparse() before sys_startgui().
>
> I'm preparing a PR.
>
>
>
> Le mer. 1 sept. 2021 à 12:13, Antoine Rousseau  a
> écrit :
>
>> confirmed here (linux).
>> seems to happen since 95b614656cd62214d6779014e5173d8af697814b
>> (2021-08-18 23:57:14   "simplified audio device handling and scheduler")
>>
>>
>>
>> Le mar. 31 août 2021 à 11:36, Lucas Cordiviola  a
>> écrit :
>>
>>> Building the current (571ad34) on Linux/Win the extra folder is not
>>> shown in Pd's Browser.
>>>
>>> --
>>> Mensaje telepatico asistido por maquinas.
>>>
>>>
>>>
>>>
>>> ___
>>> Pd-dev mailing list
>>> Pd-dev@lists.iem.at
>>> https://lists.puredata.info/listinfo/pd-dev
>>>
>>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] "extra" folder is not showing its content in Pd's browser.

[Antoine Rousseau]

the problem is that s_main::sys_main() first calls s_inter::sys_startgui(),
which calls s_inter::sys_do_startgui() which then calls
s_path::sys_set_extrapath() (send extrapath to GUI),
before it calls s_main::sys_afterargparse() which calls
s_path::sys_setextrapath (init extrapath for the OS).

I suggest just calling sys_afterargparse() before sys_startgui().

I'm preparing a PR.



Le mer. 1 sept. 2021 à 12:13, Antoine Rousseau  a
écrit :

> confirmed here (linux).
> seems to happen since 95b614656cd62214d6779014e5173d8af697814b (2021-08-18
> 23:57:14   "simplified audio device handling and scheduler")
>
>
>
> Le mar. 31 août 2021 à 11:36, Lucas Cordiviola  a
> écrit :
>
>> Building the current (571ad34) on Linux/Win the extra folder is not
>> shown in Pd's Browser.
>>
>> --
>> Mensaje telepatico asistido por maquinas.
>>
>>
>>
>>
>> ___
>> Pd-dev mailing list
>> Pd-dev@lists.iem.at
>> https://lists.puredata.info/listinfo/pd-dev
>>
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] "extra" folder is not showing its content in Pd's browser.

[Antoine Rousseau]

confirmed here (linux).
seems to happen since 95b614656cd62214d6779014e5173d8af697814b (2021-08-18
23:57:14   "simplified audio device handling and scheduler")



Le mar. 31 août 2021 à 11:36, Lucas Cordiviola  a
écrit :

> Building the current (571ad34) on Linux/Win the extra folder is not
> shown in Pd's Browser.
>
> --
> Mensaje telepatico asistido por maquinas.
>
>
>
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] writing exploits in Pd (Re: [PD] [file])

[Antoine Rousseau]

>
> however, externals are free to *not* use `sys_open` so that could be
> easily circumvented


yes. I was mostly concerned about user written Pd patches that would be
opened by a libpd app, like Pd(Droid)Party, MobMuPlat or so.
If the developer of the app could lock the write permission to a predefined
user directory, it would be safer to try opening patches from other users...
In the worst case you only could lose other patches or related data.

Thinking a bit more: actually most mobile APIs already provide such a
security...

Le mar. 31 août 2021 à 16:51, IOhannes m zmoelnig  a
écrit :

> On 8/31/21 4:37 PM, Antoine Rousseau wrote:
> >>
> >> i wonder whether it would be possible (with Pd>=0.42) to create a patch
> >> that creates a gui-plugin on the fly.
> >> if this is true, then you can already do everything that [file] allows
> you
> >> to do - and much more
> >
> >
> > yes, but [file] will be extremely useful in the "-nogui" and libpd
> contexts.
>
> yes definitely. and much more.
> i didn't write [file] to write exploits but to be useful.
>
> >
> > BTW, and about the "exploits", I'm wondering if this would be feasible to
> > implement a safety lock callable from a libpd based application, that
> would
> > restrict the write permission (of every Pd object) to a given list of
> > directories.
>
> we could probably restrict `sys_open` and friends.
> however, externals are free to *not* use `sys_open` so that could be
> easily circumvented.
>
> mfgasdr
> IOhannes
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] writing exploits in Pd (Re: [PD] [file])

[Antoine Rousseau]

>
> i wonder whether it would be possible (with Pd>=0.42) to create a patch
> that creates a gui-plugin on the fly.
> if this is true, then you can already do everything that [file] allows you
> to do - and much more


yes, but [file] will be extremely useful in the "-nogui" and libpd contexts.

BTW, and about the "exploits", I'm wondering if this would be feasible to
implement a safety lock callable from a libpd based application, that would
restrict the write permission (of every Pd object) to a given list of
directories.


Le mar. 31 août 2021 à 15:12, Christof Ressi  a
écrit :

> The exploit successfully changes my MIDI settings and adds search paths,
> but unfortunately it crashes with a completely wiped stack before showing
> me the Tk dialog :-(
> On 31.08.2021 14:33, IOhannes m zmoelnig wrote:
>
> On 8/31/21 1:05 PM, IOhannes m zmoelnig wrote:
>
>
> ¹ i wonder whether it would be possible (with Pd>=0.42) to create a patch
> that creates a gui-plugin on the fly.
> if this is true, then you can already do everything that [file] allows you
> to do - and much more.
>
>
>
> like with the attached patch.
>
> i've tested this on Linux, macOS and Windows (where i have an msys
> installation and some folders that might make the exploit work - but which
> might not be present on your machine).
>
> running the patch will add a few search-paths to your preferences and
> probably modify your MIDI-settings.
> apart from that, it shouldn't do any harm (though i wouldn't recommend to
> run it if you have a show tonight).
> use at your own risk.
>
> gmasdr
> IOhannes
>
> ___pd-l...@lists.iem.at mailing 
> list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] -stderr garbled

[Antoine Rousseau]

Sorry, my fault I guess, i didn't test with -stderr...
I can try to fix, but not before the end of the week.


Le lun. 23 août 2021 à 12:53, Christof Ressi  a
écrit :

> Hi,
>
> in this commit, "print_anything()" and "print_list()" now (ab)uses the new
> "startlogpost()" function for printing individual pd atoms. However, for
> "-stderr" and custom printhooks this will accidentally print "verbose(2) "
> before each atom.
>
> I would suggest to add another function "logatom()" - analogous to
> "postatom()" - which would only print the atom (without a newline) and omit
> the "verbose(N) " header.
>
> Christof
> On 23.08.2021 10:50, Roman Haefeli wrote:
>
> Hi
>
> Since f16dd5ec34 (I believe) everything printed to stderr is garbled.
> For instance, when doing:
>
> [list a b 12(
> |
> [print]
>
> in 'pd -stderr', I get:
>
> ~~~
> verbose(2): print: listverbose(2):  averbose(2):  bverbose(2):  12
> ~~~
>
> Without '-stderr', the print output looks fine in the Pd console.
>
> Roman
>
>
> ___
> Pd-dev mailing 
> listpd-...@lists.iem.athttps://lists.puredata.info/listinfo/pd-dev
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Using pd_bind and pd_findbyclass to access data from another external

[Antoine Rousseau]

...except that pd_findbyclassname doesn't exist in m_pd.h ;-)



Le mer. 20 janv. 2021 à 23:13, Antoine Rousseau  a
écrit :

> It's "pd_findbyclass" that wasn't working, because he was asking for a
> t_class* which had actually another value than the one he was really
> looking for.
>
> He could have asked for the right t_class* value by calling
> "pd_findbyclassname" first.
> Or he can share the variable, either using "extern" and ensuring the right
> order of loading of the 2 externals, or grouping both objects into the same
> binary file (i.e only one "external").
>
>
>
> Le mer. 20 janv. 2021 à 22:46, Eric Lennartson 
> a écrit :
>
>> Millers and Antoine's solution were, what solved the problem.
>>
>> On Wed, Jan 20, 2021, 1:39 PM Alexandre Torres Porres 
>> wrote:
>>
>>> Em ter., 19 de jan. de 2021 às 22:55, Jonathan Wilkes via Pd-dev <
>>> pd-dev@lists.iem.at> escreveu:
>>>
>>>> Sounds like a use case for pd_findbyclassname
>>>>
>>>
>>> I'm confused. I thought Eric said pd_findbyclassname didn't work for
>>> this in this case.
>>>
>>> Em qua., 20 de jan. de 2021 às 13:49, Eric Lennartson <
>>> lennartsone...@gmail.com> escreveu:
>>>
>>>> Thanks all this solved the problem!
>>>>
>>>
>>> "this" what?
>>>
>> ___
>> Pd-dev mailing list
>> Pd-dev@lists.iem.at
>> https://lists.puredata.info/listinfo/pd-dev
>>
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Using pd_bind and pd_findbyclass to access data from another external

[Antoine Rousseau]

It's "pd_findbyclass" that wasn't working, because he was asking for a
t_class* which had actually another value than the one he was really
looking for.

He could have asked for the right t_class* value by calling
"pd_findbyclassname" first.
Or he can share the variable, either using "extern" and ensuring the right
order of loading of the 2 externals, or grouping both objects into the same
binary file (i.e only one "external").



Le mer. 20 janv. 2021 à 22:46, Eric Lennartson  a
écrit :

> Millers and Antoine's solution were, what solved the problem.
>
> On Wed, Jan 20, 2021, 1:39 PM Alexandre Torres Porres 
> wrote:
>
>> Em ter., 19 de jan. de 2021 às 22:55, Jonathan Wilkes via Pd-dev <
>> pd-dev@lists.iem.at> escreveu:
>>
>>> Sounds like a use case for pd_findbyclassname
>>>
>>
>> I'm confused. I thought Eric said pd_findbyclassname didn't work for this
>> in this case.
>>
>> Em qua., 20 de jan. de 2021 às 13:49, Eric Lennartson <
>> lennartsone...@gmail.com> escreveu:
>>
>>> Thanks all this solved the problem!
>>>
>>
>> "this" what?
>>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Using pd_bind and pd_findbyclass to access data from another external

[Antoine Rousseau]

hi,

I would say the problem comes from you declaring send_test_class as static
in both files, so 2 independent variables are created.

What you can do is declaring send_test_class without "static" in the first
file:
t_class *send_test_class;

then using the "extern" keyword in the second file:
extern t_class *send_test_class;

Even better, you could create a header file like "sender_test_class.h", in
which you put both the "extern" class declaration and
the definition of the t_send_test structure, so you don't have to repeat
yourself (you'll still need to actually declare the class, without
"extern", in the first file).

You also need to be sure that the first class is loaded before, like:
[declare -lib sender -lib receiver]
else the receiver object won't load because of link error due to missing
symbol "send_test_class".

Le mar. 19 janv. 2021 à 21:39, Miller Puckette via Pd-dev <
pd-dev@lists.iem.at> a écrit :

> That's indeed the difference - a c object like "send_test_class" can't
> be shared beteen different object modules loaded separately into Pd.  This
> is one reason people have sometimes put multiple externals into a single
> object file.
>
> You could have both externs have the same  "family name" (like
> "array define" and "array set") - then they can both be defined in the
> same C object file "binarytree.[extent]".
>
> cheers
> Miller
>
> On Tue, Jan 19, 2021 at 11:38:22AM -0800, Eric Lennartson wrote:
> > Hello all,
> >
> > I've been working on trying to send data between different externals, but
> > I'm not doing something quite right. I've looked at the code in
> d_global.c
> > as well as for send and receive.
> > The only difference I can see is that mine is not all in the same .c file
> > while in the pd source it is.
> >
> > Here's the external with the data. Just an int for now, but it will be
> > holding a binary tree later.
> >
> > static t_class *send_test_class;
> > typedef struct _send_test {
> >t_object  x_obj;
> >t_symbol* name;
> >int value;
> > }t_send_test;
> >
> > static void *send_test_new(t_symbol *s, t_floatarg f) {
> >t_send_test *x = (t_send_test *)pd_new(send_test_class);
> >x->name = s;
> >x->value = f;
> >pd_bind(>x_obj.ob_pd, s); // bind to the name we're given
> >post("send_test created with name %s, and value %d", x->name->s_name,
> > x->value);
> >return(x);
> > }
> >
> > static void send_test_free(t_send_test *x) {
> >pd_unbind(>x_obj.ob_pd, x->name); // unbind when deleted
> > }
> >
> > void send_test_setup(void) {
> >send_test_class = class_new(gensym("send_test"),
> >  (t_newmethod)send_test_new,
> >  (t_method)send_test_free,
> >  sizeof(t_send_test),
> >  CLASS_NOINLET,
> >  A_DEFSYM,
> >  A_DEFFLOAT,
> >  0);
> > }
> >
> > And here's the receiver.
> >
> > static t_class *send_test_class;
> >
> > static t_class *rcv_test_class;
> >
> > typedef struct _send_test {
> >t_object  x_obj;
> >t_symbol* name;
> >int value;
> > }t_send_test;
> >
> > typedef struct _rcv_test {
> >t_object  x_obj;
> >t_symbol* name;
> >
> >int value;
> > } t_rcv_test;
> >
> > static void *rcv_test_new(t_symbol *s) {
> >t_rcv_test *x = (t_rcv_test *)pd_new(rcv_test_class);
> >x->name = s;
> >t_send_test* sender = (t_send_test*)pd_findbyclass(x->name,
> > send_test_class);
> >
> > x->value = sender->value;
> > post("sender value is %d", sender->value);
> > post("rcv_test created with name %s, and value %d", x->name->s_name,
> > x->value);
> > return(x);
> > }
> >
> > static void rcv_test_free(t_rcv_test *x) {}
> >
> > void rcv_test_setup(void) {
> >rcv_test_class = class_new(gensym("rcv_test"),
> >(t_newmethod)rcv_test_new,
> >(t_method)rcv_test_free,
> > sizeof(t_rcv_test),
> > CLASS_NOINLET,
> > A_DEFSYM,
> >
> > 0);
> > }
> >
> > What exactly is it that I'm doing wrong?
>
> > ___
> > Pd-dev mailing list
> > Pd-dev@lists.iem.at
> >
> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!Mih3wA!VoxPg_QV2Wia0Bhqv5t54R15b6iXu3DV1JfxM_8o6mhkR8gzvwWWu2gwPZVM$
>
>
>
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] qsort_r failure building puredata on Android?

[Antoine Rousseau]

This doesn't explain though why it works in certain situations.
Using ofxPd or PdDroidParty for example, I don't remember I've ever had
that issue. But (at least for ofxPd) it was compiled with c++ compiler; I
don't know if this can matter.
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Default value for unconnected signal input, or connection detection in an external

[Antoine Rousseau]

>
> This is pretty adventurous :-)


admittedly  ;-)
but it works quite well since ... 2001! (although I remember I had to help
fixing one or two "bugs" in Pd to make it possible...)

Antoine


Le jeu. 19 mars 2020 à 19:38, Christof Ressi  a
écrit :

> This is pretty adventurous :-)
> On 19.03.2020 19:17, Antoine Rousseau wrote:
>
>
> also you can have a look to moonlib/dinlet~, which (I think) does what you
> want.
> source is there:
> https://github.com/MetaluNet/moonlib/blob/externals/moonlib/dinlet%7E.c
>
>
>
>
>
> Le jeu. 19 mars 2020 à 16:41, x nor  a écrit :
>
>> Ahh okay, these are not main signal inputs (the first inlet is used for
>> something already).. and I want to just use `m_pd.h` so I guess I'll add
>> the creation arguments.
>> Good to know about CLASS_MAINSIGNALIN float setting for the first inlet
>> though!
>> Thanks!
>> -Alex
>>
>> On Thu, Mar 19, 2020 at 8:28 AM Christof Ressi 
>> wrote:
>>
>>> Hi,
>>>
>>> for the first inlet you can simply set the float field passed to
>>> CLASS_MAINSIGNALIN. This is actually done by many Pd objects, e.g.
>>> "phasor~", "osc~", etc.
>>>
>>> For other inlets it's a bit more tricky. If you're ok with including
>>> "m_imp.h", you can use "obj_findsignalscalar" which returns a pointer
>>> to the scalar value for the Nth signal inlet.
>>>
>>> Christof
>>> On 19.03.2020 16:16, x nor wrote:
>>>
>>> Hey Christof and dev list,
>>>
>>> Christof,
>>> I think it was you that did the work that allowed for a default value
>>> for unconnected [inlet~] in the inlet_features branch that didn't get
>>> merged?
>>>
>>> I'm wondering, is there a way to do that with externals as is without
>>> modifying the pure data source? Either that or a way to detect connectivity?
>>>
>>> I want to provide some audio rate controls to an external I'm writing
>>> but not *require* them for operation. 0 isn't a good default for some of
>>> these (amp or frequency multiplication).
>>> If its not possible to provide defaults or detect connectivity (so i can
>>> provide my own defaults) I'll probably just provide optional creation args
>>> to opt in to these audio rate parameters.. but that just ends up being a
>>> lot more work so I figured I'd ask first :)
>>>
>>> Thanks,
>>> Alex
>>>
>>> ___
>> Pd-dev mailing list
>> Pd-dev@lists.iem.at
>> https://lists.puredata.info/listinfo/pd-dev
>>
>
> ___
> Pd-dev mailing 
> listpd-...@lists.iem.athttps://lists.puredata.info/listinfo/pd-dev
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Default value for unconnected signal input, or connection detection in an external

[Antoine Rousseau]

also you can have a look to moonlib/dinlet~, which (I think) does what you
want.
source is there:
https://github.com/MetaluNet/moonlib/blob/externals/moonlib/dinlet%7E.c





Le jeu. 19 mars 2020 à 16:41, x nor  a écrit :

> Ahh okay, these are not main signal inputs (the first inlet is used for
> something already).. and I want to just use `m_pd.h` so I guess I'll add
> the creation arguments.
> Good to know about CLASS_MAINSIGNALIN float setting for the first inlet
> though!
> Thanks!
> -Alex
>
> On Thu, Mar 19, 2020 at 8:28 AM Christof Ressi 
> wrote:
>
>> Hi,
>>
>> for the first inlet you can simply set the float field passed to
>> CLASS_MAINSIGNALIN. This is actually done by many Pd objects, e.g.
>> "phasor~", "osc~", etc.
>>
>> For other inlets it's a bit more tricky. If you're ok with including
>> "m_imp.h", you can use "obj_findsignalscalar" which returns a pointer to
>> the scalar value for the Nth signal inlet.
>>
>> Christof
>> On 19.03.2020 16:16, x nor wrote:
>>
>> Hey Christof and dev list,
>>
>> Christof,
>> I think it was you that did the work that allowed for a default value for
>> unconnected [inlet~] in the inlet_features branch that didn't get merged?
>>
>> I'm wondering, is there a way to do that with externals as is without
>> modifying the pure data source? Either that or a way to detect connectivity?
>>
>> I want to provide some audio rate controls to an external I'm writing but
>> not *require* them for operation. 0 isn't a good default for some of these
>> (amp or frequency multiplication).
>> If its not possible to provide defaults or detect connectivity (so i can
>> provide my own defaults) I'll probably just provide optional creation args
>> to opt in to these audio rate parameters.. but that just ends up being a
>> lot more work so I figured I'd ask first :)
>>
>> Thanks,
>> Alex
>>
>> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] array/table and canvas memory management

[Antoine Rousseau]

[clone] allows to easily create multiple tables encapsulated into
abstractions. This way you can kinda emulate multi-dimensional tables...

Le jeu. 30 janv. 2020 à 20:43, x nor  a écrit :

> The analysis data sets will have a variable number of tables depending on
> the analysis parameters and the audio that was analyzed so unless I want to
> do mega long table with offsets or have the user overshoot the count of
> tables, that would be rather cumbersome. As an example, one data set has
> 3x42 tables of data...
> Would be cool if PD had multi dimensional tables readable by the standard
> table objects..
>
> -Alex
>
>
> On Thu, Jan 30, 2020 at 10:46 AM Christof Ressi 
> wrote:
>
>> Since the only problem is managing (de)allocation of arrays, another
>> option would be to ask the user to provide the arrays and pass the symbol
>> to the external. The external can then resize it with garray_resize_long()
>> to the required size. Might save you some headache :-)
>>
>> > via the approach you gave me some weeks ago (binbuf).
>>
>> Binbufs are useful for dynamically creating patch files, but adding a
>> single garray to a canvas is much easier:
>>
>> pd_vmess((t_pd *)mycanvas, gensym("obj"), "iisss", 0, 0, gensym("array"),
>> gensym("define"), arraysymbol);
>>
>> This basically sends the message "obj 0 0 array define arraysymbol" to
>> the canvas like in dynamic patching.
>>
>> Christof
>> On 30.01.2020 19:14, x nor wrote:
>>
>> Thanks for your insights Christof!
>>
>> I would like to be able to access the data outside my external,
>> specifically with tabread4~.
>> I'm thinking I will create a canvas per data set, managed by my object,
>> that has all the tables I need, via the approach you gave me some weeks ago
>> (binbuf).
>> The private data structure approach is interesting but part of the point
>> is being able to utilize this data outside of the externals I write, but
>> either way it is good to know about that appraoch.
>>
>> -Alex
>>
>> On Tue, Jan 28, 2020 at 6:41 AM Christof Ressi 
>> wrote:
>>
>>> Hi,
>>>
>>> So my question is: if I allocate an array/table in an external, do I
>>> have to manage its de-allocation or is there some sort of reference counter?
>>>
>>> A graphical array always belongs to a canvas and it will be
>>> automatically be destroyed when the canvas is freed. Destroying a single
>>> graphical array in code is a bit tricky and you need stuff from private
>>> headers like g_canvas.h.
>>>
>>> How about with canvases?
>>> If I create a canvas per analysis data set, do I have to manage the
>>> canvas de-allocation?
>>>
>>> This is how you create a private canvas in the object constructor:
>>>
>>> pd_vmess(_canvasmaker, gensym("canvas"), "i", 0, 0, 100, 100, 
>>> 10);x_canvas = (t_canvas *)s__X.s_thing;
>>>
>>> pd_vmess((t_pd *)x_canvas, gensym("pop"), "i", 0);
>>>
>>> Such a canvas will have an owner, but it doesn't actually belong to a
>>> glist, so you have to free it yourself in the destructor:
>>>
>>> pd_free((t_pd *)x_canvas);
>>>
>>> Note that if you want to create a table outside the object constructor,
>>> you should cache the current canvas with canvas_getcurrent() in the
>>> constructor. Before creating a new canvas you have to push the cached
>>> canvas with pd_push() or canvas_setcurrent() and in the end pop it with
>>> pd_pop() or canvas_unsetcurrent(). This makes sure that the canvas gets an
>>> owner and doesn't go to the root canvas list.
>>>
>>> If I de-allocate an array (inside a canvas I create in code or not) and
>>> some other object is using that array, what happens?
>>>
>>> A crash :-) Unless the object uses a gpointer, so it can check whether
>>> the glist is still alive.
>>>
>>> I just want to stress that managing canvasses/garrays programmatically
>>> is not officially supported by the Pd API. It's possible with the
>>> workarounds shown above, but I wouldn't recommend it unless it's 100%
>>> necessary.
>>>
>>> ---
>>>
>>> I'd like to be able to load several sets of tables with a single object,
>>> and then access that data with an arbitrary number of resynthizers.
>>>
>>> You might reconsider whether you really need actual Pd tables to do
>>> this. I think you only need them if the data should be accessible as tables
>>> outside your own externals. Otherwise I would strongly recommend to use
>>> your own private data structure and share it among your externals.
>>>
>>> Just create a faux-class like this:
>>>
>>> static t_class *data_class;
>>>
>>> typedef struct _data {
>>> t_pd d_pd;
>>> // your data..
>>> } t_data;
>>>
>>> // in the setup routine:
>>> data_class = class_new(gensym("data private"),0, 0, sizeof(t_data), 
>>> CLASS_PD, 0);
>>>
>>> There's no need to (de)allocate instances with pd_new()/pd_free(), you
>>> can just do getbytes()/freebytes(), but you have to make sure to set d_pd
>>> to data_class. See the "alist" class in x_list.c.
>>>
>>> Because t_data is a Pd class, you can now safely bind instances to
>>> symbols with 

Re: [PD-dev] algo for sequencing merges

[Antoine Rousseau]

Personally I would be happy to have the "trackable print" PR (
https://github.com/pure-data/pure-data/pull/464) merged in one of the next
releases! It's a minor addition but could often be helpful.

My other PR ("gpointer for table objects" [667], "threaded soundfiler"
[655] and "flag-less declare" [440]) are more research-oriented...

Cheers

Ant1
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] switch bugs.puredata.info to github?

[Antoine Rousseau]

yes, it makes sense.

Le dim. 6 oct. 2019 à 22:36, Federico Camara Halac  a
écrit :

> +1 Perhaps it would also be useful to include a tiny issue template, or
> some simple guidelines to include the minimum needed to understand the
> issue; and, a link to the sourceforge if people don't want to join github
>
> On Sun, Oct 6, 2019 at 10:06 PM Alexandre Torres Porres 
> wrote:
>
>> Great, I like the idea too
>>
>> Em dom, 6 de out de 2019 às 12:40, Max 
>> escreveu:
>>
>>> On 06.10.19 21:07, Christof Ressi wrote:
>>> >> so I wondered whether we should direct the people to the github
>>> tracker
>>> >> instead.
>>> >
>>> > My opinion: yes!
>>>
>>> +1
>>>
>>> sourceforge and subversion smell funny
>>>
>>>
>>>
>>> ___
>>> Pd-dev mailing list
>>> Pd-dev@lists.iem.at
>>> https://lists.puredata.info/listinfo/pd-dev
>>>
>> ___
>> Pd-dev mailing list
>> Pd-dev@lists.iem.at
>> https://lists.puredata.info/listinfo/pd-dev
>>
>
>
> --
> fdch.github.io
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] declare (again)

[Antoine Rousseau]

Thanks!
I think we needed to realize fully the implications of the recent changes,
before imagining that it could be even simpler...

Antoine Rousseau
  http://www.metalu.net <http://metalu.net> __
http://www.metaluachahuter.com/
<http://www.metaluachahuter.com/compagnies/al1-ant1/>



Le mar. 11 sept. 2018 à 13:07, Dan Wilcox  a écrit :

> Also, I like that this simple, yet elegant approach does not need to
> remove or override the explicit -path or -lib flags at all. I'm not sure
> why we didn't think of it when I wrote the initial PR a year ago.
>
> On Sep 11, 2018, at 1:04 PM, Dan Wilcox  wrote:
>
> Yeah. I find "you need to tell PD where to look" make sense, but adding
> "and HOW it needs to look" becomes the issue.
>
> On Sep 11, 2018, at 1:02 PM, Julian Brooks  wrote:
>
> +1
> You only understand how non-intuitive current [declare] is once you've
> attempted to describe it simply to a roomful of learners.
> Not saying current situation isn't a huge improvement over where we were
> umpteen years ago but if there's the option to make it even simpler & more
> straightforward plus portable - yes please.
>
> J.
>
> On Tue, 11 Sep 2018 at 11:42, Dan Wilcox  wrote:
>
>> Actually, that's not a bad idea at the expense of a little more
>> searching. [declare] then behaves more like the lua loader which searches
>> for both binary and script modules, which I find relatively easy to use. I
>> don't think this would break existing patches and would also honor the
>> relative path restrictions for self contained projects, where specifying a
>> relative path starting with ./ or ../ only searches locally.
>>
>> On Sep 11, 2018, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote:
>>
>> Date: Tue, 11 Sep 2018 11:42:00 +0200
>> From: Antoine Rousseau 
>> To: pd-dev 
>> Subject: Re: [PD-dev] declare (again)
>> Message-ID:
>> 
>> Content-Type: text/plain; charset="utf-8"
>>
>>
>> relatively easy code change
>>
>>
>> ...  so I propose step 2 as PR #440 !
>>
>> cheers
>>
>>
> 
> Dan Wilcox
> @danomatika <http://twitter.com/danomatika>
> danomatika.com
> robotcowboy.com
>
>
>
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] declare (again)

[Antoine Rousseau]

>
> relatively easy code change
>

...  so I propose step 2 as PR #440 !

cheers

Antoine Rousseau
  http://www.metalu.net <http://metalu.net> __
http://www.metaluachahuter.com/
<http://www.metaluachahuter.com/compagnies/al1-ant1/>



Le mar. 11 sept. 2018 à 00:36, Antoine Rousseau  a
écrit :

> I'm also very enthusiast with the new version to come!
>
> One thing (among many others!) makes me very happy: the new behavior of
> [declare -path]. Pd now finds any declared library, wherever the user chose
> to place it, provided the location (of the library directory) is either
> relative, standard, or declared in preferences. I think this is the way to
> build portable patches and abstractions.
>
> I would like to propose some steps further:
>
> - 1: I think we should now discourage patch builders from using -stdpath
> or -stdlib, as it would restrain the portability of their patches; this is
> only a matter of rewriting (one more time...) the declare help patch.
>
> - 2: why not introducing a new [declare] functionality, which would allow
> to avoid the flag (-path -lib -stdpath -stdlib) and cumulate -lib and -path
> declarations.
> So we would have for instance:
> [declare zexy iemlib]
>  instead of
> [declare -path zexy -lib zexy -path iemlib -lib iemlib]
> This would in some way resuscitate the old [import] from pd-extended.
> It seems it's a relatively easy code change, so it's more a matter of
> decision.
>
> It seems to me that the community would benefit from adopting rapidly a
> new unified way to declare any library, whether binary or abstraction.
>
> Antoine Rousseau
>   http://www.metalu.net <http://metalu.net> __
> http://www.metaluachahuter.com/
> <http://www.metaluachahuter.com/compagnies/al1-ant1/>
>
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] declare (again)

[Antoine Rousseau]

I'm also very enthusiast with the new version to come!

One thing (among many others!) makes me very happy: the new behavior of
[declare -path]. Pd now finds any declared library, wherever the user chose
to place it, provided the location (of the library directory) is either
relative, standard, or declared in preferences. I think this is the way to
build portable patches and abstractions.

I would like to propose some steps further:

- 1: I think we should now discourage patch builders from using -stdpath or
-stdlib, as it would restrain the portability of their patches; this is
only a matter of rewriting (one more time...) the declare help patch.

- 2: why not introducing a new [declare] functionality, which would allow
to avoid the flag (-path -lib -stdpath -stdlib) and cumulate -lib and -path
declarations.
So we would have for instance:
[declare zexy iemlib]
 instead of
[declare -path zexy -lib zexy -path iemlib -lib iemlib]
This would in some way resuscitate the old [import] from pd-extended.
It seems it's a relatively easy code change, so it's more a matter of
decision.

It seems to me that the community would benefit from adopting rapidly a new
unified way to declare any library, whether binary or abstraction.

Antoine Rousseau
  http://www.metalu.net <http://metalu.net> __
http://www.metaluachahuter.com/
<http://www.metaluachahuter.com/compagnies/al1-ant1/>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] bug in dollar sign handling

[Antoine Rousseau]

>
> this one has been fixed in the mean time. just grab the latest master.
>

yep, sorry I was lost in the history while going back in the past. So this
is fixed.

I proposed a resolution (PR #425) of the bug I reported (dollarsym
regression). Wasn't related to backslashes changes at all, actually...

Antoine Rousseau
  http://www.metalu.net <http://metalu.net> __
http://www.metaluachahuter.com/
<http://www.metaluachahuter.com/compagnies/al1-ant1/>



Le mer. 5 sept. 2018 à 12:39, Christof Ressi  a
écrit :

> > also, another bug currently damages patches at save time
>
> this one has been fixed in the mean time. just grab the latest master.
>
> Christof
>
> Gesendet: Mittwoch, 05. September 2018 um 10:57 Uhr
> Von: "Antoine Rousseau" 
> An: pd-dev 
> Betreff: Re: [PD-dev] bug in dollar sign handling
>
> also, another bug currently damages patches at save time, with lines such
> as:
> #X restore 145 407 #X f 16;
> (missing semicolon and line break; obviously the patch file is not
> functional anymore).
>
>
> Le mer. 5 sept. 2018 à 01:32, Antoine Rousseau  anto...@metalu.net]> a écrit :
> Hi,
>
>
> dollar sign handling seems currently broken on master:
> [b]-[symbol $0-$0]-[print]
> returns:
> print: symbol 1003-\\$01003
> I guess it could come from the recent backslashes related
> additions.___ Pd-dev mailing
> list Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev[https://lists.puredata.info/listinfo/pd-dev]
>
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] bug in dollar sign handling

[Antoine Rousseau]

also, another bug currently damages patches at save time, with lines such
as:
#X restore 145 407 #X f 16;
(missing semicolon and line break; obviously the patch file is not
functional anymore).


Le mer. 5 sept. 2018 à 01:32, Antoine Rousseau  a
écrit :

> Hi,
>
> dollar sign handling seems currently broken on master:
> [b]-[symbol $0-$0]-[print]
> returns:
> print: symbol 1003-\\$01003
> I guess it could come from the recent backslashes related additions.
>
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] Fwd: bug in dollar sign handling

[Antoine Rousseau]

Hi,

dollar sign handling seems currently broken on master:
[b]-[symbol $0-$0]-[print]
returns:
print: symbol 1003-\\$01003
I guess it could come from the recent backslashes related additions.
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] How to customize Pd.app for macOS?

[Antoine Rousseau]

>
> how can I include the prefs file into the app?
>

sorry I can't see a way to do this...
certainly a macos expert (Dan?) will have a better idea.


Antoine Rousseau
  http://www.metalu.net <http://metalu.net> __
http://www.metaluachahuter.com/
<http://www.metaluachahuter.com/compagnies/al1-ant1/>


2017-12-13 13:41 GMT+01:00 Roman Haefeli <reduz...@gmail.com>:

> On Mit, 2017-12-13 at 13:39 +0100, Antoine Rousseau wrote:
> > you could just add "-open {your_path}" into prefs?
>
> I actually would prefer such a simple approach, but how can I include
> the prefs file into the app?
>
> Roman
>
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] 0.48-1 release plans

[Antoine Rousseau]

Hey, these are good news!

However I wish #205 had label "bug/fix", because path management is
currently really confusing IMO.
I can't wait for a simple and durable solution...

#227 also is quite desirable in order to have consistent rendering across
OSes and completed zoom.

Thanks for all!
Antoine

2017-11-29 17:46 GMT+01:00 Miller Puckette :

> To pd dev:
>
> I've been trying to merge all the various pull requests that are bug fixes
> and cleanups (holding off for now on any 'enhancements' - I think getting
> bugs fixed is going to be challenge enough.
>
> I think some of the clang t_int vs. intstuff still needs straightening out;
> it sometimes conflicted with other changes and I don't have a compile chain
> handy that complains properly when int sizes get changed without a cast.
>
> I put this right in 'head' on a clone of my own repo; it compiles OK for me
> here on linux/64 and widows-32 so I think it's provisionally working, but
> needs
> lots of testing.
>
> If there's no reason not to I'll just throw that all in my own 'head' and
> push
> it all back to the git repo.
>
> Meanwhile I've got m own list of 1/2 dozen bugs to try to fix.  I'll be
> fooling
> with that over the next week or so.  With luck I can get a 0.48-1 'test'
> version out by early next week .
>
> cheers
> Miller
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Gem on iOS

[Antoine Rousseau]

Hi Chris,

you also could have to look to POF (https://github.com/Ant1r/ofxPof), which
is a deken-installable set of GL(ES) objects that can be used to build a
libPd application (iOS/Android/raspi/desktop).

It is based on openFrameworks (POF = Pd + OF), and is BSD-licensed.

Cheers,

Antoine Rousseau
  http://www.metalu.net <http://metalu.net> __
http://www.metaluachahuter.com/
<http://www.metaluachahuter.com/compagnies/al1-ant1/>


2017-10-08 20:17 GMT+02:00 Cjniven <cjni...@gmail.com>:

> Good point. I might just have to look into using openFrameworks for
> graphics instead.
>
> Thanks,
>
> -c
>
> Sent from my iPhone
>
> > On Oct 8, 2017, at 2:00 PM, IOhannes m zmölnig <zmoel...@iem.at> wrote:
> >
> >> On 10/08/2017 07:43 PM, Cjniven wrote:
> >> Hi everyone,
> >>
> >> Does anyone know if it's possible to run Gem patches on iOS? I was
> looking into using ofxGem but it doesn't seem to be supported on iOS
> because of the use of shared memory.
> >>
> >
> > i wonder how you imaging to run GPL-software like Gem on iOS.
> >
> > gfamsdr
> > IOhannes
> >
> > ___
> > Pd-dev mailing list
> > Pd-dev@lists.iem.at
> > https://lists.puredata.info/listinfo/pd-dev
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] message crash when using menuclose on patch

[Antoine Rousseau]

I don't think closing a patch using its $0 could fix this:
"if a message sent to a channel has the effect of changing immediately the
number of receivers for this channel, then Pd is likely to crash."
It would also be the case if sending to a $0 related channel I think ;
while clearing a subpatch (aka dynamic patching) doesn't lead to this
condition.

OTOH I really don't know why it seemed to be different in Pd-extended or
older vanillas...


Antoine Rousseau
  http://www.metalu.net <http://metalu.net> __
http://www.metaluachahuter.com/
<http://www.metaluachahuter.com/compagnies/al1-ant1/>


2017-09-29 10:26 GMT+02:00 Dan Wilcox <danomat...@gmail.com>:

> I'm not really a huge fan of dynamics patching for this as simply open and
> close seems so much cleaner. That being said, I wish there was a vanilla
> way to close an open patch using it's $0, etc. That's more of a matter for
> my suggestions for a more general canvas info etc object...
>
> The funny thing is that I never experienced this issue before, way back to
> the original system running in 2006. I think the difference is the hardware
> was slower, so the list might have been traversed before the patch was
> closed whereas now the patch closes more quickly while the message is
> mid-list. Or vice versa.
>
> I haven't experienced this with Pd-extended either and have played many
> shows, including the one in Nov at the Pd-con. It's only with trying to
> adapt this setup to vanilla that I'm running into things. (Yes, I've still
> been using extended for some older sets but am transitioning now.)
>
> Maybe this is something fixed in extended?
>
> On Sep 28, 2017, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote:
>
> That said, I think that @Dan could use dynamic patching; I've just
> successfully tested creating/destroying abstractions every 5 millis, while
> the abstractions were forwarding a value updated every millisecond from
> master patch, without any crash.
>
>
> 
> Dan Wilcox
> @danomatika <http://twitter.com/danomatika>
> danomatika.com
> robotcowboy.com
>
>
>
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] message crash when using menuclose on patch

[Antoine Rousseau]

>
> modifying a linked list while iterating over it

yes. And if (for this name) there is only one receiver (the one which is
deleted when the message is received), then the end of the list is reached
before trying to access next element, so it *should* not crash.

Strangely, trying to 'menuclose' self top-level patch (through
[namecanvas]) crashes Pd, excepting when the patch isn't yet saved (newly
created one).

That said, I think that @Dan could use dynamic patching; I've just
successfully tested creating/destroying abstractions every 5 millis, while
the abstractions were forwarding a value updated every millisecond from
master patch, without any crash.



Antoine Rousseau
  http://www.metalu.net <http://metalu.net> __
http://www.metaluachahuter.com/
<http://www.metaluachahuter.com/compagnies/al1-ant1/>


2017-09-27 22:38 GMT+02:00 IOhannes m zmölnig <zmoel...@iem.at>:

> On 09/27/2017 04:51 PM, Antoine Rousseau wrote:
> > I just found out that if 2 instances of the same file are opened,
> sending a
> > "pd-PatchName.pd menuclose" crashes Pd. I don't know if it is related to
> > your problem.
>
> iirc that has been reported on the tracker (on sf, i think) a while ago.
>
> the problem is basically that you are modifying a linked list while
> iterating over it (which is forbidden in a lot of high level languages
> for a good reason).
>
> afaict, iemguts' [canvasdelete] object provides a sane way to delete
> open patches (or instantiated abstractions).
> (but it's GPLed, so it might be of limited use if your target platform
> is libpd/iOS)
>
> cmx
> IOhannes
>
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] message crash when using menuclose on patch

[Antoine Rousseau]

Instead of closing it from the main patch, did you try asking the song
patch to close itself after a small delay (10ms)? And making sure that no
communication occurs between them at that moment.

Other test: dynamic patching in a subpatch of the main patch (maybe
worse...)

Of course a bug fix would be better...

Antoine Rousseau
  http://www.metalu.net <http://metalu.net> __
http://www.metaluachahuter.com/
<http://www.metaluachahuter.com/compagnies/al1-ant1/>


2017-09-27 13:02 GMT+02:00 Dan Wilcox <danomat...@gmail.com>:

> I've been trying to track down a bug which crashes pd when switching song
> patches in my performance system. I first recall seeing this with 0.47-1
> and never had a problem before with Pd-extended. It's a showstopper and
> keeping me from using PdParty for what I built it for.
>
> Basically, I have a main performance patch for audio io, playlist
> management, transport control, and OSC communication. Songs are separate
> patches that are opened and closed when running through the playlist using
> the "pd open $file $dir" and "pd-PatchName.pd menu close 1" messages. The
> song patches communicate with the performance patch via send and receive
> objects.
>
> The problem comes where sometimes closing a patch leads to a crash. I've
> tested numerous approaches and opening is not a problem, only the close
> message. Digging through with the debugger shows the crash generally
> happens in pd_typedmess and it seems as though messages being sent to the
> global send objects between the patches are being processed in a patch even
> after it was just closed which ends in a BAD_ACCESS. At least that's as far
> as I've been able to figure things out. I can provide backtraces, etc.
>
> I'm hoping to figure this out as I've been wanting to develop for and use
> my newer system but this is really killing any chance so far.
>
> 
> Dan Wilcox
> @danomatika <http://twitter.com/danomatika>
> danomatika.com
> robotcowboy.com
>
>
>
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] [pure-data:patches] #571 fix the way signal scalars are searched into the list of inlets of an object.

[Antoine Rousseau]

---

** [patches:#571] fix the way signal scalars are searched into the list of  
inlets of an object.**

**Status:** open
**Group:** bugfix
**Created:** Wed Feb 24, 2016 05:19 PM UTC by Antoine Rousseau
**Last Updated:** Wed Feb 24, 2016 05:19 PM UTC
**Owner:** Miller Puckette


The function m_obj.c/obj_findsignalscalar(t_object x, int m) was incorrectly 
counting non-signal inlets, when looking for 'm'th signal inlet.

Apparently this never caused any visible bug, nowhere except in moonlib/dinlet~ 
external, for which this fix is required.


---

Sent from sourceforge.net because pd-dev@lists.iem.at is subscribed to 
https://sourceforge.net/p/pure-data/patches/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/pure-data/admin/patches/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Pd-dev mailing list
Pd-dev@lists.iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] [pure-data:patches] #570 help browser improvement and help patch search fix for abs

[Antoine Rousseau]

---

** [patches:#570] help browser improvement and help patch search fix for abs**

**Status:** open
**Group:** bugfix
**Created:** Wed Feb 24, 2016 03:07 PM UTC by Antoine Rousseau
**Last Updated:** Wed Feb 24, 2016 03:07 PM UTC
**Owner:** Miller Puckette
**Attachments:**

- 
[0001-Don-t-expand-declared-paths-to-helpbrowser-root.patch](https://sourceforge.net/p/pure-data/patches/570/attachment/0001-Don-t-expand-declared-paths-to-helpbrowser-root.patch)
 (2.4 kB; text/x-patch)
- 
[0002-Strip-abstraction-name-before-searching_help.patch](https://sourceforge.net/p/pure-data/patches/570/attachment/0002-Strip-abstraction-name-before-searching_help.patch)
 (2.3 kB; text/x-patch)


Two patches relative to help patches and help browser.

The first one avoids to add subdirs of paths declared in preferences to the 
first column of the Help Browser, but only adds the paths themselves instead.

For example, if "myLib/" directory is declared in preferences, and if myLib/ 
contains foo/ and bar/ subdirs, only "myLib/" entry is added to the first 
column of Help Browser, instead of "foo/" and "bar/" as currently.


The second strips the path component from an abstraction's filename before 
searching for its help patch ; this way, help file "foo/abs-help.pd" or 
"foo/help-abs.pd" would be found
for a [foo/abs] abstraction.
Currently such help file is not found, as pd looks for "foo/foo/abs-help.pd". 


---

Sent from sourceforge.net because pd-dev@lists.iem.at is subscribed to 
https://sourceforge.net/p/pure-data/patches/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/pure-data/admin/patches/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Pd-dev mailing list
Pd-dev@lists.iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] [pure-data:patches] #568 Update INSTALL.txt and tcl/Makefile.am

[Antoine Rousseau]

---

** [patches:#568]  Update INSTALL.txt and tcl/Makefile.am**

**Status:** open
**Group:** bugfix
**Created:** Mon Dec 28, 2015 02:33 PM UTC by Antoine Rousseau
**Last Updated:** Mon Dec 28, 2015 02:33 PM UTC
**Owner:** Miller Puckette
**Attachments:**

- 
[0002-Update-tcl-Makefile.am-to-include-pd_deken.tcl.patch](https://sourceforge.net/p/pure-data/patches/568/attachment/0002-Update-tcl-Makefile.am-to-include-pd_deken.tcl.patch)
 (1.7 kB; text/x-patch)
- 
[0001-Update-some-linux-parts-of-INSTALL.txt.patch](https://sourceforge.net/p/pure-data/patches/568/attachment/0001-Update-some-linux-parts-of-INSTALL.txt.patch)
 (1.3 kB; text/x-patch)


Update tcl/Makefile.am to include pd_deken.tcl (which was not properly 
installed)
and  
Update some linux parts of INSTALL.txt



---

Sent from sourceforge.net because pd-dev@lists.iem.at is subscribed to 
https://sourceforge.net/p/pure-data/patches/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/pure-data/admin/patches/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Pd-dev mailing list
Pd-dev@lists.iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Pof = Pd OpenFrameworks externals

[Antoine Rousseau]

 What’s the bug with ofxPd?


Actually it's not a bug, but it seems there is problem when compiling with
latest pdlib. But I did not personally experiment this, as I use an older
version. The log (see in french: http://codelab.fr/5696#p28677 ) was
related to undefined references to expr_setup, pd_fft, mayer_fft...


2015-03-29 17:10 GMT+02:00 Dan Wilcox danomat...@gmail.com:

 On Mar 29, 2015, at 8:33 AM, pd-dev-requ...@lists.iem.at wrote:

 Anyaway you should have a bug compiling ofxPd, which you can resolve by
 downloading a previous version of ofxPd (github/ofxPd/branch/tags/0.8.4).


 What’s the bug with ofxPd? Since I wrote ofxPd, I’d like to fix it, if
 possible. :D

 
 Dan Wilcox
 @danomatika
 danomatika.com
 robotcowboy.com




-- 
Antoine Rousseau ant1rousse...@gmail.com
http://www.metaluachahuter.com/compagnies/al1-ant1/
http://al1ant1.free.fr
___
Pd-dev mailing list
Pd-dev@lists.iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Pof = Pd OpenFrameworks externals

[Antoine Rousseau]

I will try. However the guy who had this issue was compiling on Linux, with
the Makefile I guess.

2015-03-29 18:55 GMT+02:00 Dan Wilcox danomat...@gmail.com:

 That’s related to my updates to the latest libpd which removed a few
 sources no longer in pd vanilla and added built in support for building the
 externals. You see this happen if you had an older version of ofxPd/libpd,
 upgraded to the latest version (git pull), then try to build without having
 cleaned the project. Can you experiment with this? I keep seeing people
 having trouble but I think it’s a pretty simple fix. Also, after upgrading,
 the project files need to be regenerated to handle the changes in files.
 This shouldn’t be a problem for Linux+Codeblocks since it just calls the
 Makefiles anyway.

 
 Dan Wilcox
 @danomatika
 danomatika.com
 robotcowboy.com

 On Mar 29, 2015, at 12:44 PM, Antoine Rousseau ant1rousse...@gmail.com
 wrote:

 What’s the bug with ofxPd?


 Actually it's not a bug, but it seems there is problem when compiling with
 latest pdlib. But I did not personally experiment this, as I use an older
 version. The log (see in french: http://codelab.fr/5696#p28677 ) was
 related to undefined references to expr_setup, pd_fft, mayer_fft...


 2015-03-29 17:10 GMT+02:00 Dan Wilcox danomat...@gmail.com:

 On Mar 29, 2015, at 8:33 AM, pd-dev-requ...@lists.iem.at wrote:

 Anyaway you should have a bug compiling ofxPd, which you can resolve by
 downloading a previous version of ofxPd (github/ofxPd/branch/tags/0.8.4).


 What’s the bug with ofxPd? Since I wrote ofxPd, I’d like to fix it, if
 possible. :D

 
 Dan Wilcox
 @danomatika
 danomatika.com
 robotcowboy.com




 --
 Antoine Rousseau ant1rousse...@gmail.com
 http://www.metaluachahuter.com/compagnies/al1-ant1/
 http://al1ant1.free.fr





-- 
Antoine Rousseau ant1rousse...@gmail.com
http://www.metaluachahuter.com/compagnies/al1-ant1/
http://al1ant1.free.fr
___
Pd-dev mailing list
Pd-dev@lists.iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Pof = Pd OpenFrameworks externals

[Antoine Rousseau]

 ofxPd.h: Aucun fichier ou dossier de ce type

seems that you didn't install the dependencies (see README.md) ;-)
ofxPd, ofxJSON, ofxUnicode and ofxZipPass.
Anyaway you should have a bug compiling ofxPd, which you can resolve by
downloading a previous version of ofxPd (github/ofxPd/branch/tags/0.8.4).
You will have another minor compilation issue with ofxUnicode, which i
mentioned in HACKS.txt file. Refer to codelab Pof's thread in french
langage (http://codelab.fr/5696) for a quick fix (updated checked.h file
for utf8cpp).

About cast error in snprintf(selfname,16 , pof%x, (unsigned int)this),
it's a 64bit issue so I didn't fix it yet, but replacing (unsigned
int)this by (void*)this should do it.

bise !
ant1


2015-03-29 13:14 GMT+02:00 Cyrille Henry c...@chnry.net:

 hello Antoine,

 i'm trying to test pof.
 i'm following the instructions, but i have some problems.

 for the standalone project :
 I cd in the exampleStandalone folder, not in the example folder as
 advertised in the documentation.

 make give this error :

 In file included from src/main.cpp:2:0:
 src/testApp.h:9:19: fatal error: ofxPd.h: Aucun fichier ou dossier de ce
 type
  #include ofxPd.h

 using the codeblock workspace, i had to simlink
 /home/chnry/of/of_v0.8.4_linux64_release/libs/openFrameworksCompiled/
 project/linux64
 to
 /home/chnry/of/of_v0.8.4_linux64_release/libs/openFrameworksCompiled/
 project/linux
 but in the end, i had the same error.



 building as pd externals, make gives :

 In file included from src/ofApp.cpp:7:0:
 ../../../addons/ofxPof/src/pofBase.h: In constructor
 ‘pofBase::pofBase(_class*)’:
 ../../../addons/ofxPof/src/pofBase.h:30:50: error: cast from ‘pofBase*’
 to ‘unsigned int’ loses precision [-fpermissive]
 snprintf(selfname,16 , pof%x, (unsigned int)this);
   ^
 make[1]: *** [obj/linux64/Release/src/ofApp.o] Erreur 1
 make[1]: quittant le répertoire « /home/chnry/of/of_v0.8.4_
 linux64_release/addons/ofxPof/buildExternal »
 make: *** [Release] Erreur 2

 i'm running ubuntu linux (14.04)


 cheers
 cyrille

 Le 26/03/2015 14:29, Antoine Rousseau a écrit :

 Hi all,

 my name is Antoine Rousseau (sourceforge/github/puredata/codelab :
 ant1r).
 I'm using Pd since 2000, to build musical and visual machines (see
 http://metalu.net and al1ant1.free.fr http://al1ant1.free.fr).

 I wrote moonlib externals long time ago. (BTW maybe I will have some time
 one day to update these libs ; will it be possible I have an access to the
 sourceforge for this purpose ?)


 I'm happy to announce the publication of a new project : Pof = Pd +
 openFrameworks :
 https://github.com/Ant1r/ofxPof

 It consists of pd externals written in OF bringing mid-level openGL
 functions (and some additional utilities), so you can build an app entirely
 in pd patchs, and get it working for every OF-supported OSes
 (Linux/OSX/Win/Android/IOS) with the help of ofxPd (https://github.com/
 danomatika/ofxPd).

 Of course Pof has similarities with Gem ; one of the main differences is
 that the rendering is done by a parallel thread, to avoid audio clicking ;
 this is done by copying the pd tree to a specific rendering tree. This has
 some implications on the pd tree : in Pof you cannot render the same object
 multiple times.

 Multitouch events are also managed by the rendering thread, using an
 optimized inverted tree, for an event at a given place to be captured by
 the last drawn object at this place. The touch management is (for now) only
 meaningful in a 2D design : depth (z) is not taken into account.

 Being written in C++/OF, tons of tedious work are made easy ; that's why
 some utilities I needed for the work I did were written into Pof : threaded
 file downloading, XML/JSON support, file utils.

 This project has only been tested on Linux (Ubuntu 12.04 32bit)  and
 Android for the moment.
 An Android patch player APK file and a built pof.pd_linux are available
 for download in the releases github tab (https://github.com/Ant1r/
 ofxPof/release). Contributions are welcome to have it running on more
 systems.

 I hope this will contribute to make the Pd ecosystem even stronger !

 Regards

 --
 Antoine Rousseau ant1rousse...@gmail.com mailto:ant1rousse...@gmail.com
 
 http://www.metalu.net/
 http://www.metaluachahuter.com/compagnies/al1-ant1/
 http://al1ant1.free.fr



 ___
 Pd-dev mailing list
 Pd-dev@lists.iem.at
 http://lists.puredata.info/listinfo/pd-dev


 ___
 Pd-dev mailing list
 Pd-dev@lists.iem.at
 http://lists.puredata.info/listinfo/pd-dev




-- 
Antoine Rousseau ant1rousse...@gmail.com
http://www.metaluachahuter.com/compagnies/al1-ant1/
http://al1ant1.free.fr
___
Pd-dev mailing list
Pd-dev@lists.iem.at
http://lists.puredata.info/listinfo/pd-dev