[PD] Pd-extended 0.43 updates: lots of new editing features

Mon Jul 11 06:36:21 CEST 2011

On Jul 10, 2011, at 11:28 PM, Jonathan Wilkes wrote:

>
>
> --- On Mon, 7/11/11, Ivica Ico Bukvic <ico at vt.edu> wrote:
>
>> From: Ivica Ico Bukvic <ico at vt.edu>
>> Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing  
>> features
>> To: "Jonathan Wilkes" <jancsika at yahoo.com>, "Hans-Christoph  
>> Steiner" <hans at at.or.at>
>> Cc: pd-list at iem.at
>> Date: Monday, July 11, 2011, 2:56 AM
>>
>>
>> Jonathan Wilkes <jancsika at yahoo.com>
>> wrote:
>>
>>>
>>>
>>> --- On Sun, 7/10/11, Hans-Christoph Steiner <hans at at.or.at>
>> wrote:
>>>
>>>> From: Hans-Christoph Steiner <hans at at.or.at>
>>>> Subject: Re: [PD] Pd-extended 0.43 updates: lots
>> of new editing
>>> features
>>>> To: "Jonathan Wilkes" <jancsika at yahoo.com>
>>>> Cc: "Ivica Ico Bukvic" <ico at vt.edu>, pd-list at iem.at
>>>> Date: Sunday, July 10, 2011, 7:25 PM
>>>>
>>>> On Jul 9, 2011, at 8:07 PM, Jonathan Wilkes
>> wrote:
>>>>
>>>>>
>>>>>
>>>>> --- On Sat, 7/9/11, Hans-Christoph Steiner
>> <hans at at.or.at>
>>>> wrote:
>>>>>
>>>>>> From: Hans-Christoph Steiner <hans at at.or.at>
>>>>>> Subject: Re: [PD] Pd-extended 0.43
>> updates: lots
>>>> of new editing
>>>>>> features
>>>>>> To: "Jonathan Wilkes" <jancsika at yahoo.com>
>>>>>> Cc: "Ivica Ico Bukvic" <ico at vt.edu>, pd-list at iem.at
>>>>>> Date: Saturday, July 9, 2011, 10:38 PM
>>>>>>
>>>>>> On Jul 9, 2011, at 1:48 AM, Jonathan
>> Wilkes
>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --- On Sat, 7/9/11, Hans-Christoph
>> Steiner
>>>> <hans at at.or.at>
>>>>>> wrote:
>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>>> The problem with forks is if
>> improvements
>>>> don't
>>>>>> migrate
>>>>>>>> upstream.
>>>>>>>
>>>>>>> I think it's both a problem-with and
>> a
>>>> cause-of.
>>>>>>
>>>>>> Yup, that makes sense.
>>>>>>
>>>>>>>> Then we don't benefit from
>> sharing the
>>>>>>>> fixes.  Making things migrate
>>>> upstream takes
>>>>>> time in
>>>>>>>> itself.
>>>>>>>
>>>>>>> How does one figure out who has the
>>>> responsibility to
>>>>>> make sure
>>>>>>> things migrate upstream (for
>> example:
>>>> [initbang] and
>>>>>> [closebang])?
>>>>>>
>>>>>> Mostly by someone deciding its important
>> enough
>>>> that they
>>>>>> want to work
>>>>>> on it themself, and then lots of testing
>> and
>>>>>> communication.
>>>>>
>>>>> Ok.  So in patch id#2838176, what is
>> Guenter's
>>>> idea for a clean
>>>>> implementation of tooltips that you were
>> referring
>>>> to?  I didn't
>>>>> find anything on the user or dev list.
>>>>
>>>> Hmm, I can't remember what Günter's proposal was,
>> but I do
>>>> have a
>>>> vague idea of how to do it cleanly.  I think it
>> should
>>>> be similar to
>>>> the way its done in Max/MSP.  Basically there is
>> a
>>>> standard function,
>>>> something like nlet_info(), which returns the
>> tooltip
>>>> info.
>>>
>>> Where would one define the standard function?
>>>
>>>
>>>> Pd would
>>>> then check whether an object had that function
>> when it
>>>> loaded the
>>>> binary, and if so register it in the tooltips.
>>>
>>> This brings up an issue I've been wondering about since
>> learning a
>>> little more about the canvas editor: why does the pd
>> gui send 'motion'
>>> messages to pd?  Why not, for example, just have a
>> tag for an inlet
>>> rectangle and bind <Enter> and <Leave> to
>> it?  Then you'd only be
>>> sending messages from the gui for the events you care
>> about, instead of
>>> tons of "motion" messages that don't trigger anything.
>>
>> I may be way off the mark here, if I  recall correctly
>> I think that info is used for dragging stuff and similar
>> actions.
>
> Yes, it is, but I was just thinking that extending a wire from an  
> outlet, which sends a message to pd every mouse motion and walks  
> through the objects in the glist to see if it hit a box, could be  
> simplified if you just handled it on the gui end.  Then only send a  
> message if the wire connection is successful, or if there is a  
> disconnection.
>
> But I guess you'd still have to send a message every pixel you drag  
> an object in editmode anyway.

For connections/cords, you've illustrated it well.  Pd only tracks  
whether they are connected or not, so it doesn't need to know the  
position, especially during creation.  For moving boxes, Pd would  
mostly not need to know about the location, GUI objects would, but  
that would be within the GUI object.  The one thing I can think of  
where Pd needs to know the location is with inlets and outlets, since  
the position could change the program.

Changing the connection logic to be entirely in the GUI would be a  
good place to start on this.  I think pd-gui would just need to  
communicate using the 'connect' message, then the disconnect, and  
which cord is under the magic glass.

.hc

>
>>
>>>
>>> -Jonathan
>>>
>>>>
>>>> .hc
>>>>
>>>>
>>>>>>>> Try getting a patch into the
>> Linux
>>>> kernel,
>>>>>>>> that'll make Pd seem like cake
>> ;-)
>>>>>>>
>>>>>>> Yes, I would hope that making changes
>> to the
>>>> core of
>>>>>> the largest
>>>>>>> free software project in the history
>> of
>>>> computing is a
>>>>>> wee bit more
>>>>>>> difficult than making changes to Pd.
>>>>>>
>>>>>> Actually, there are much bigger projects
>> than
>>>> Linux, things
>>>>>> like
>>>>>> Debian are quite a bit larger in scale.
>>>>>
>>>>> I read a white paper on total development
>> cost of a
>>>> linux distro and
>>>>> just remembered "linux".  I think the distro
>> in
>>>> the paper was Fedora
>>>>> 9, which was estimated to be almost an order
>> of
>>>> magnitude more
>>>>> expensive than the Linux kernel.
>>>>>
>>>>> -Jonathan
>>>>>
>>>>>>
>>>>>> .hc
>>>>>>
>>>>>>>
>>>>>>> -Jonathan
>>>>>>>
>>>>>>>>
>>>>>>>> .hc
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> -Jonathan
>>>>>>>>>
>>>>>>>>>> And
>>>>>>>>>> anything assigned to
>> Miller and
>>>> reviewed
>>>>>>>> positively by
>>>>>>>>>> IOhannes I'm
>>>>>>>>>> going to defer any action
>> on until
>>>> Miller
>>>>>>>> responds.
>>>>>>>>>>
>>>>>>>>>> .hc
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -Jonathan
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>> _______________________________________________
>>>>>>>>>>>> Pd-list at iem.at
>>>>>>>>>>>> mailing list
>>>>>>>>>>>> UNSUBSCRIBE and
>>>> account-management
>>>>>> ->
>>>>>>>> http://lists.puredata.info/listinfo/pd-list
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>> ----------------------------------------------------------------------------
>>>>>>>>
>>>>>>>> "[T]he greatest purveyor of
>> violence in
>>>> the world
>>>>>> today
>>>>>>>> [is] my own government." - Martin
>> Luther
>>>> King,
>>>>>> Jr.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>> ----------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>     http://at.or.at/hans/
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>>
>>> ----------------------------------------------------------------------------
>>>>
>>>> The arc of history bends towards justice.
>>>>    - Dr. Martin Luther
>>>> King, Jr.
>>>>
>>>>
>>>>
>>
>>
>> Ivica Ico Bukvic, D.M.A
>> Composition, Music Technology
>> Director, DISIS Interactive Sound & Intermedia Studio
>> Director, L2Ork LinuxLaptop Orchestra
>> Assistant Co-Director, CCTAD
>> CHCI, CS, and Art (by courtesy)
>> Virginia Tech
>> Department of Music
>> Blacksburg, VA 24061-0240
>> (540) 231-6139
>> (540) 231-5034 (fax)
>> disis.music.vt.edu
>> l2ork.music.vt.edu
>> ico.bukvic.net
>>

----------------------------------------------------------------------------

As we enjoy great advantages from inventions of others, we should be  
glad of an opportunity to serve others by any invention of ours; and  
this we should do freely and generously.         - Benjamin Franklin