Howdy all,
I am working on the 3rd iteration of a long term project we use for sound spatialization at ZKM. The current sound server was built using Pd and runs internally using libpd.
We have many older projects which use CAF (Core Audio File) audio files (.caf or .caff) and I would need to be able to read them with Pd. I could find or make an external just for this file format, but I was thinking it could be generally useful to have this supported by [soundfiler], et al directly.
CAF specification: https://developer.apple.com/library/archive/documentation/MusicAudio/Refere… <https://developer.apple.com/library/archive/documentation/MusicAudio/Refere…>
The format is basically a container that takes different data formats, one being LPCM as in WAV & AIFF. We could post an error and ignore any compressed files. As the file structure is similar to WAV & AIFF, it seems like it wouldn't be too much work to add uncompressed CAF support to Pd and would work conceptually in the same manner.
CAF files offer a couple of advantages:
* 64-bit offsets for nigh-unrestricted durations (so file sizes > 4 GB)
* recording could be faster as it allows for appending data
* open format that is supported outside of macOS/iOS
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
---
** [bugs:#1317] float trims to int in expr**
**Status:** open
**Group:** v0.48
**Created:** Sun Apr 07, 2019 01:55 PM UTC by Anonymous
**Last Updated:** Sun Apr 07, 2019 01:55 PM UTC
**Owner:** nobody
in a fresh install, i create the expr object with the argument '1.0'.
upon losing focus, the '1.0' turns to a '1'.
---
Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
(correct subject line)
Ah, good point. Doing a string look up might not be the best thing, although maybe we can check performance metrics. It's not like there isn't string handling going on already and I doubt that gettext is doing allocations during a lookup.
> On Sep 13, 2018, at 5:40 PM, pd-dev-request(a)lists.iem.at wrote:
>
> From: IOhannes m zmölnig <zmoelnig(a)iem.at <mailto:zmoelnig@iem.at>>
>
> On 9/13/18 3:00 PM, Dan Wilcox wrote:
>> For the developers, could we consider building Pd with gettext support in the core? Then we could translate most of the internal strings without having to resort to string matching on the GUI side.
>
>
> what would be the benefit of that?
> conceptually, i *quite* like the idea of not doing translation work in
> the audio thread.
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
In my configuration,
udp sending (netsend -u)Â from a linux machine to macOSX machine on a
local ethernet network,
I experienced that the udp connection closed when trying to send data
if the dest port was not reachable on target machine.
Jean-Yves
On 27/03/2019 12:00, pd-dev-request(a)lists.iem.at wrote:
> Message: 2
> Date: Tue, 26 Mar 2019 09:52:33 -0700
> From: Miller Puckette<msp(a)ucsd.edu>
> To: Dan Wilcox<danomatika(a)gmail.com>
> Cc: Christof Ressi<christof.ressi(a)gmx.at>, pd-dev
> <pd-dev(a)lists.iem.at>
> Subject: Re: [PD-dev] netsend/netreceive UDP ignore ECONNREFUSED
> Message-ID:<20190326165233.GE27681(a)ucsd.edu>
> Content-Type: text/plain; charset=us-ascii
>
> Incidentally, I get the same behavior (send fails if to a nonexistent local
> port, but keeps trying if non-local) on linux.
>
> cheers
> Miller
>
> On Tue, Mar 26, 2019 at 05:41:58PM +0100, Dan Wilcox wrote:
>> That's good to know.
>>
>> I think I have this working. I will do some cleanup and a push, then you can test.
>>
>>> On Mar 26, 2019, at 4:43 AM, Christof Ressi<christof.ressi(a)gmx.at> wrote:
>>>
>>> sorry for spamming the list today. @Dan you have probably read this already:https://stackoverflow.com/questions/41231270/econnrefused-errors-on…
>>>
>>> turns out that at least on my system (Windows 7) [netsend -u] only closes the socket when sending to a non-reachable port on*localhost*. sending to any other (existing or non-existing) host won't close the socket. this means that there's even less reason to consider this a feature and I'm not sure if there are really any patches out there which depend on this behaviour.
>>>
>>> Christof
>> --------
>> Dan Wilcox
>> @danomatika<http://twitter.com/danomatika>
>> danomatika.com<http://danomatika.com/>
>> robotcowboy.com<http://robotcowboy.com/>
>>
>>
>>
Howdy all,
I've been making some proposal work for updates to netsend/netreceive.
One issue is making UDP sending ignore connection refused errors. I have this working by catching the return value from recv():
/* keep UDP alive */
if (sys_sockerrno() == ECONNREFUSED && x->x_protocol == SOCK_DGRAM)
return;
(I added sys_sockerrno() to return the socket errno.)
From my reading on the socket API, sending a UDP message conceptually shouldn't care about whether the receiver is there. However this is detected on a lower networking layer and propagated up to the application layer where it can be used or ignored.
My questions are:
1. Should this ignore silently and not close the connection? I notice mrpeach [udpsend] seems to ignores the first try, then closes the socket on the next failure. However, I like keeping the socket as no errors are thrown and you can easily break than re-establish UDP sending/receiving. This works well with the [netsend] dst & source relays.
2. Should this be a creation argument, say -k? I imagine there are plenty of patches which expect the socket to be closed automatically and respond to a 0 from the connection outlet. On the other hand, as UDP is "connectionless" my thinking is that the conceptual "connection" of a UDP [netsend] (aka outlet) refers to the internal socket and not necessarily that the destination is reachable. With TCP, the connection state more obviously refers to 1-1 connection with the other side.
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
Hello.
I'm coding externals for the first time.
I want to construct an arbitrary symbol inside my code, to use as an
address for routing other messages that the external sends. For example, if
I have destinations foo-1, foo-2, bar-3, and bar-4 in Pd, I would like to
tell the outlet to convert a string to symbol that would be made from a
constant string ("foo") plus a float (1, 2...), feed that to the right
inlet of a [send] object, and then send the actual message to the other
inlet. I looked at snprintf(), but it writes to a char buffer/pointer, and
none of the functions I can find will accept this in place of symbol. The
number of destinations will be changeable, and I'd prefer not to just
hardcode them all and save them in memory.
Obviously, the [symbol] object outputs a symbol made from user input, but I
haven't located the code where that happens.
Can anyone give me a clue? Can I convert char[] to symbol?
Much appreciated!
-Chuckk
--
http://www.badmuthahubbard.com
That's a similar concept to Cocoa's NSTrackingArea. It's basically a rectangle in a view that you attach which then receives mouse enter, leave, move, down, up, & drag events. You can update the position and size whenever.
https://developer.apple.com/documentation/appkit/nstrackingarea?language=ob… <https://developer.apple.com/documentation/appkit/nstrackingarea?language=ob…>
I could imagine something similar in Pd, say a [mousearea] object. Also, updating [cnv] with similar functionality would be useful. [mousearea] could be used for arbitrary areas for control interaction and drawing of other objects while [cnv] could be used to create simple graphical regions for things like piano keys. I know there have been different approaches in this area, so it might be helpful to take a look (DesireData, PurrData, etc).
I think this would complement a general, canvas wide set of [mouse] objects. I started by following the existing approach and split functionality into [mouse], [mouseup], and [mousemotion]. Another approach would be to use a single [mouse] object with a status symbol in addition to x & y.
> On Mar 17, 2019, at 12:15 PM, Chris McCormick <chris(a)mccormick.cx> wrote:
>
> Hi Dan,
>
> Thanks so much for looking at this.
>
> What I really want as an end-user is to be able to know "has this particular rectangle received mouse-down, mouse-motion, or mouse-up?"
>
> I think this would bring huge flexibility in allowing people to build complex user interfaces at the patch level. Things like ribbon controllers max/min selectors, click-and-hold buttons etc.
>
> Cheers,
>
> Chris.
>
> On 16/3/19 10:01 am, Dan Wilcox wrote:
>> Howdy all,
>> I played around a bit with forwarding canvas mouse click events to a [mouse] object. This works fine using a bind to a global "#mouse" symbol, however this means all objects receive events from all canvases.
>> How can I change this to be local canvas only, as in only [mouse] objects within the canvas receive the events? I was thinking to generate a symbol with the canvas id ala how [openpanel] and [savepanel] work:
>> sprintf(buf, "d%lx", (t_int)x);
>> x->x_s = gensym(buf);
>> x->x_canvas = canvas_getcurrent();
>> pd_bind(&x->x_obj.ob_pd, x->x_s)
>> However, this means the canvas mouse function would need to generate the equivalent symbol each time the event is called in order to check if anything is bound to it. This seems wasteful. I suppose I could add a cached symbol somewhere, maybe to the g_canvas instance struct, however I'd like avoid that.
>> --------
>> Dan Wilcox
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
> On Mar 17, 2019, at 5:53 PM, pd-dev-request(a)lists.iem.at wrote:
>
> Date: Sun, 17 Mar 2019 17:53:32 +0100
> From: "Christof Ressi" <christof.ressi(a)gmx.at <mailto:christof.ressi@gmx.at>>
> To: pd-dev <pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>>
> Subject: Re: [PD-dev] Fw: Re: local canvas-only pd_bind
> Message-ID:
> <trinity-747b5b71-f76b-4152-b9e3-32b84eb46d99-1552841612281@3c-app-gmx-bs56>
>
> Content-Type: text/plain; charset=UTF-8
>
>> But, no mouseup unfortunately.
>
> on mousedown, the widget could assign itself to a "grab" variable, and a mouseup event sends a message to the object who has the current grab.
Basically yes. I've implemented a similar strategy in a "poor man's UIKit" for my lua environment ala Apple's UIKit: https://github.com/danomatika/loaf-ingredients/tree/master/hui <https://github.com/danomatika/loaf-ingredients/tree/master/hui>
The lowest (sub)view that received the mouse down becomes the active subview and receives the eventual mouse up, no matter where it may occur. Mouse position is scaled to match the coordinates of the (sub)view.
> another question: if we choose to go with a widget, can we just add this functionality to [cnv] ? after all, it can be made invisible by setting the visible width and height to 0.
It might be good to design this in such a way that it can be used within the other UIs and possible externals. Again, UIKit's approach to this is nice in that you only have to think about what';s going on within you're view as mouse events are only propagated down when the mouse is over and interstices with the lowest (sub)view.
In any case, this is getting more complicated that my original intention (simple [mouse] analogy to [key]), however I am familiar with some of the approaches and we could mock up a test proposal. If this can be done in a no-to-complicated manner, it's a win for everyone.
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
hi katja,
personally I would prefer 2), simply because it allows you to build custom widgets as Pd abstractions. a tracking area can be built quite easily with GOP.
> Mouseup is a bit of a maverick: you want to be alerted regardless of
> mouse position, i.e. any canvas or even outside Pd's territory.
> Otherwise one could easily get the equivalent of a dangling midinote.
that's an important point! I've worked a bit with GUI toolkits like Qt and usually it's implemented so that if you click a widget, it has the current "grab", and whenever you release the mouse, the widget which has the grab gets the mouseup event. we can do a similar thing in Pd.
but there are more general questions about parent/child releationships:
with iemguts you directly specify the parent canvas from which you want to receive mouse events. the bad thing is that [receivecanvas] is context sensitive: you have to know where your abstraction is being used and give the right parent level!! this is quite bad for implementing widgets, which should work anywhere. so I'm actually a bit wary about the iemguts approach (although I've brought it up).
on the other hand, when you receive mouse events from a GOP, you can do that on any level as long as the object is visible. you can easily nest GOPs and every GOP which is under the cursor will receive the click message. however, there's no event passing like in Qt: all widgets in question get the event (probably starting from the inmost canvas). this means that there can be more than one "grab" - rather a "grab list" which is then notified for mouseup events.
another question for mouseup events is if only widgets with a "grab" should get the event - or also widgets which fall under the current cursor position? the second could be handy for drop&drag funtionality. maybe this could be controlled by a creation argument/flag.
Christof
> Gesendet: Sonntag, 17. März 2019 um 16:38 Uhr
> Von: "katja" <katjavetter(a)gmail.com>
> An: "Christof Ressi" <christof.ressi(a)gmx.at>
> Cc: pd-dev <pd-dev(a)lists.iem.at>, "Dan Wilcox" <danomatika(a)gmail.com>
> Betreff: Re: [PD-dev] local canvas-only pd_bind
>
> Hello,
>
> Metoo, I'm hungry for mouse events since long. Last year I evaluated
> these approaches (as objects based on unmodified Pd):
>
> 1 - as a basic widget, a rectangle without button or label
> 2 - as a non-widget, tracking mouse events within a GOP rectangle
>
> Eventually the widget won my preference because it is easier to use,
> and because Pd's widgetbehavior infrastructure is made for such things
> after all. My implementation is almost complete except for the thing
> that sparked the current discussion: mouseup data. It would be great
> if a widget could subscribe to mouseup events, but a callback for that
> isn't available through widgetbehavior.
>
> Mouseup is a bit of a maverick: you want to be alerted regardless of
> mouse position, i.e. any canvas or even outside Pd's territory.
> Otherwise one could easily get the equivalent of a dangling midinote.
> Therefore, would it be reasonable to conceive a dedicated class
> [mouseup], every instance of which would be informed about every
> mouseup event once? Such a class could also be useful in connection
> with existing Pd GUIs, for example to turn a single-cell radiobutton
> into a momentary switch.
>
> Anyhow, the other mouse events (mousedown, coordinates) are so much
> related to position that bundling these in a single class is useful,
> be it in a widget or otherwise.
>
>
> Katja
>
> On 3/17/19, Christof Ressi <christof.ressi(a)gmx.at> wrote:
> > on the other hand, I'm not sure if many people actually need to get mouse
> > evens outside of GOP areas. I'm having a hard time coming up with useful
> > examples on the fly...
> > so a simplified version of [mouse] could just get the relative coordinates
> > of the first GOP area it can find (so you can place it anywhere inside your
> > abstraction/graph). for advanced use cases, there's always iemguts... just
> > thinking out loud.
> >
> > Christof
> >
> > Gesendet: Sonntag, 17. März 2019 um 16:07 Uhr
> > Von: "Christof Ressi" <christof.ressi(a)gmx.at>
> > An: "Dan Wilcox" <danomatika(a)gmail.com>
> > Cc: pd-dev <pd-dev(a)lists.iem.at>
> > Betreff: Re: [PD-dev] local canvas-only pd_bind
> > personally, I like the mechanism of [iemguts/receivecanvas] where you
> > specify the parent level from where to receive mouse events because it's
> > quite flexible. one problem, though, is that GOPs are a bit awkward: you
> > have to get the mouse position from the parent canvas and then substract the
> > canvasposition to get coordinates relative to the GOP. you can even hack
> > together mouse enter and leave events to create advanced widgets, but it
> > involves quite a lot of thinking.
> >
> > maybe the iemguts approach with parent levels can be somehow combined with
> > elegant GOP handling? for example, [iemguts/receivecanvas] will never send
> > mouse events if GOP is enabled on the given parent (except when someone
> > opens it via the context menu), so maybe in this case the object could
> > report mouse events relative to the GOP area. working with parent levels has
> > the advantage that you can freely choose the location within you patch
> > structure, e.g. you can put it in a subpatch and you just have to increase
> > the parent level by 1.
> >
> > Christof
> > Gesendet: Sonntag, 17. März 2019 um 14:28 Uhr
> > Von: "Dan Wilcox" <danomatika(a)gmail.com>
> > An: "Christof Ressi" <christof.ressi(a)gmx.at>
> > Cc: pd-dev <pd-dev(a)lists.iem.at>, "Chris McCormick" <chris(a)mccormick.cx>
> > Betreff: Re: [PD-dev] local canvas-only pd_bind
> > Some good ideas.
> >
> > I agree that GOP is basically a natural analogy to a tracking area already,
> > so that might be a good place to look. Perhaps this can be rolled into the
> > name canvas mechanism whereby a named canvas will receive mouse events when
> > GOP is enabled?
> >
> >>
> >> Hi Dan, thanks for looking into this! This is really, really needed.
> >>
> >> I think with the [mouse] object, [mousearea] can be easily created as a subpatch with GOP enabled, so I don't think we need a dedicated GUI object for that.
> >>
> >> regarding [cnv]: I think getting notifications for mouse clicks would be nice (in the past, people have faked this by putting other GUI objects below the canvas, but it's really clumsy).
> >>
> >>
> >> Christof
> >
> >
> >>>
> >>> On Mar 17, 2019, at 1:38 PM, Dan Wilcox <danomatika(a)gmail.com> wrote:
> >>>
> >>> That's a similar concept to Cocoa's NSTrackingArea. It's basically a
> >>> rectangle in a view that you attach which then receives mouse enter,
> >>> leave, move, down, up, & drag events. You can update the position and
> >>> size whenever.
> >>>
> >>> https://developer.apple.com/documentation/appkit/nstrackingarea?language=ob…
> >>>
> >>> I could imagine something similar in Pd, say a [mousearea] object. Also,
> >>> updating [cnv] with similar functionality would be useful. [mousearea]
> >>> could be used for arbitrary areas for control interaction and drawing of
> >>> other objects while [cnv] could be used to create simple graphical
> >>> regions for things like piano keys. I know there have been different
> >>> approaches in this area, so it might be helpful to take a look
> >>> (DesireData, PurrData, etc).
> >>>
> >>> I think this would complement a general, canvas wide set of [mouse]
> >>> objects. I started by following the existing approach and split
> >>> functionality into [mouse], [mouseup], and [mousemotion]. Another
> >>> approach would be to use a single [mouse] object with a status symbol in
> >>> addition to x & y.
> >>
> >>
> >
> >
> > --------
> > Dan Wilcox
> > @danomatika
> > danomatika.com
> > robotcowboy.com
> >
> > _______________________________________________ Pd-dev mailing list
> > Pd-dev(a)lists.iem.at https://lists.puredata.info/listinfo/pd-dev
>
Howdy all,
I played around a bit with forwarding canvas mouse click events to a [mouse] object. This works fine using a bind to a global "#mouse" symbol, however this means all objects receive events from all canvases.
How can I change this to be local canvas only, as in only [mouse] objects within the canvas receive the events? I was thinking to generate a symbol with the canvas id ala how [openpanel] and [savepanel] work:
sprintf(buf, "d%lx", (t_int)x);
x->x_s = gensym(buf);
x->x_canvas = canvas_getcurrent();
pd_bind(&x->x_obj.ob_pd, x->x_s)
However, this means the canvas mouse function would need to generate the equivalent symbol each time the event is called in order to check if anything is bound to it. This seems wasteful. I suppose I could add a cached symbol somewhere, maybe to the g_canvas instance struct, however I'd like avoid that.
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>