[L2Ork-dev] Description of intelligent patching
Albert Graef
aggraef at gmail.com
Mon Nov 7 11:17:29 UTC 2016
Forgot to attach the test patch, here it is.
On Mon, Nov 7, 2016 at 12:16 PM, Albert Graef <aggraef at gmail.com> wrote:
> Hi Ico,
>
> thanks a lot for the explanation! So option 1 connects multiple
> corresponding in- and outlets of two selected objects, while options 2 and
> 3 do 1:n and n:1 single-in/outlet connections between one unselected and n
> selected objects, I get that. That's very useful and intuitive.
>
> I'm still grappling with the fourth option, though. If I'm not mistaken,
> this either connects different outlets from the source to the other
> selected objects, or, vice versa, one outlet from the other selected
> objects to different inlets of the target, whichever gives the most
> connections? This seems to be the least intuitive option to me, as the
> outcome is not always obvious. Maybe it would be better to do only one or
> the other, depending on whether the user holds down another shift key
> (maybe alt)? Just a suggestion...
>
> Also, I can make the fourth option crash pd-l2ork with a segfault. To
> reproduce:
>
> (1) launch the attached intelligent-patching.pd patch
>
> (2) select all 4 pack/unpack objects in the patch
>
> (3) connect outlet #3 of the left pack object with inlet #1 of the right
> unpack object
>
> => pd-l2ork crashes with SIGSEGV, gdb backtrace:
>
> #0 0x0000000000499c00 in outconnect_setvisible ()
> #1 0x000000000047788e in canvas_doconnect_doit ()
> #2 0x0000000000478778 in canvas_trymulticonnect ()
> #3 0x0000000000478825 in canvas_doconnect ()
> #4 0x0000000000481f09 in canvas_mouseup ()
> #5 0x000000000049890d in pd_typedmess ()
> #6 0x000000000049862a in pd_typedmess ()
> #7 0x00000000004a13f6 in binbuf_eval ()
> #8 0x00000000004a80cc in socketreceiver_read ()
> #9 0x00000000004a740b in ?? ()
> #10 0x00000000004a4556 in m_mainloop ()
> #11 0x00000000004a6e28 in sys_main ()
> #12 0x00007ffff63ba291 in __libc_start_main () from /usr/lib/libc.so.6
> #13 0x00000000004174da in _start ()
>
> purr-data does exactly the same, but its gdb backtrace is a little more
> informative, so I'm attaching that as well:
>
> #0 outconnect_setvisible (oc=oc at entry=0x0, vis=vis at entry=1) at
> m_obj.c:349
> #1 0x00000000004733de in canvas_doconnect_doit (x=x at entry=0x2a50c00,
> y1=0x2a4f1b0, y2=y2 at entry=0x2a55cb0, closest1=closest1 at entry=2,
> closest2=closest2 at entry=1, multi=multi at entry=1, create_undo=1)
> at g_editor.c:4024
> #2 0x00000000004742b8 in canvas_trymulticonnect (x=x at entry=0x2a50c00,
> xpos=xpos at entry=169, ypos=ypos at entry=98, which=which at entry=1,
> doit=doit at entry=1) at g_editor.c:4499
> #3 0x0000000000474365 in canvas_doconnect (x=x at entry=0x2a50c00,
> xpos=xpos at entry=169, ypos=ypos at entry=98, which=which at entry=1,
> doit=doit at entry=1) at g_editor.c:4521
> #4 0x000000000047dab9 in canvas_mouseup (x=0x2a50c00, fxpos=<optimized
> out>,
> fypos=<optimized out>, fwhich=1) at g_editor.c:4719
> #5 0x00000000004941dd in pd_typedmess (x=0x2a50c00, s=0xb7efa0,
> argc=<optimized out>, argv=<optimized out>) at m_class.c:864
> #6 0x0000000000493efa in pd_typedmess (x=x at entry=0x2a59000, s=0xb7efa0,
> argc=argc at entry=3, argv=argv at entry=0x7fffffffe370) at m_class.c:886
> #7 0x000000000049cd16 in binbuf_eval (x=<optimized out>,
> target=0x2a59000,
> target at entry=0x0, argc=argc at entry=0, argv=argv at entry=0x0) at
> m_binbuf.c:904
> #8 0x00000000004a393c in socketreceiver_read (x=0xc79d60, fd=28)
> at s_inter.c:568
> #9 0x00000000004a2c7b in sys_domicrosleep (microsec=<optimized out>,
> pollem=1)
> at s_inter.c:206
> #10 0x00000000004a2d25 in sys_microsleep (microsec=<optimized out>)
> at s_inter.c:228
> #11 0x000000000049fe56 in m_pollingscheduler () at m_sched.c:562
> #12 m_mainloop () at m_sched.c:622
> #13 0x00000000004a26e8 in sys_main (argc=<optimized out>, argv=<optimized
> out>)
> at s_main.c:335
> #14 0x00007ffff63ba291 in __libc_start_main () from /usr/lib/libc.so.6
> #15 0x0000000000417d7a in _start ()
>
> I haven't had time to look into the code yet, but will do asap if noone
> beats me to it. :)
>
> Finally, it seems that when I hold the shift key while doing connections,
> it lets me do multiple connections from the same outlet, is that right?
> This is also very useful and works great in purr-data, but in pd-l2ork
> there doesn't seem to be a way to get out of that mode again, is that a bug?
>
> Cheers,
> Albert
>
> On Mon, Nov 7, 2016 at 10:03 AM, Ivica Ico Bukvic <ico at vt.edu> wrote:
>
>> You're right, Albert. The documentation for this is thin. IIRC when I
>> committed it to the git, I think I added the explanation. Below are
>> extracted comments from the g_editor.c:
>>
>> /* FIRST OPTION: if two objects are selected and the one that is
>> originating is one of the selected objects try multi-connecting
>> all outlets into all inlets starting with the user-made one as
>> an offset */
>>
>> /* SECOND OPTION: if two or more objects are selected and the one
>> that is originating is not one of the selected, connect
>> originating
>> to all selected objects' the outlets specified by the first
>> connection */
>>
>> /* THIRD OPTION: if two or more objects are selected and the one
>> that is receiving connection is one of the selected, and the
>> target object is selected, connect nth outlet (as specified by
>> the first connection) from all selected objects into the inlet
>> of the unselected one */
>>
>> /* FOURTH OPTION: if more than two objects are selected and both
>> y1
>> and y2 are selected connect each originating object's outlet to
>> each of the outgoing objects' inlets until you run out of
>> objects
>> or outlets. This one is tricky as there is no guarrantee that
>> objects will be selected in proper visual order, so we order
>> the
>> selection from left to right and top to bottom to ensure proper
>> visual pairing. This option has two variants, A and B.
>> OPTION A VS B: we either connect outgoing to each of other
>> objects
>> (A) or incoming to all other objects (B). We determine which
>> one of
>> the two options is selected based on which condition will
>> yield more
>> successful connections. */
>>
>> As for the paste script into canvas, you should be able to copy PD patch
>> text (from the .pd file), focus onto a newly opened canvas you wish to
>> patch into, and paste and doing so should automagically paste things into
>> that patch and update canvas properties accordingly, including its size and
>> position. I think there is a variant of that where if you paste into the
>> existing canvas that has been already edited in which case canvas
>> properties like size and location are ignored while there rest is pasted
>> accordingly on top of the edited stuff. Pasting malformed text, however,
>> can result in a crashtastic paste for which pd-l2ork will inform you in the
>> console before crashing. Unfortunately, I haven't figured out yet an easy
>> way how to salvage it at that point. HTH
>>
>> Best,
>>
>> Ico
>>
>>
>> On 11/6/2016 6:45 PM, Albert Graef wrote:
>>
>> Ico, is there an explanation anywhere about how pd-l2ork's different
>> intelligent patching modes work? A quick search in the help browser didn't
>> turn up anything.
>>
>> Also, in the PdCon paper you mentioned something about "pasting script
>> code snippets directly onto the canvas". Could you please elaborate a bit
>> on that a bit as well? Sounds like this might be useful for Faust and Pure
>> externals.
>>
>> TIA,
>> Albert
>>
>> --
>> Dr. Albert Gr"af
>> Computer Music Research Group, JGU Mainz, Germany
>> Email: aggraef at gmail.com
>> WWW: https://plus.google.com/+AlbertGraef
>>
>>
>> _______________________________________________
>> L2Ork-dev mailing listL2Ork-dev at disis.music.vt.eduhttp://disis.music.vt.edu/listinfo/l2ork-dev
>>
>>
>>
>> _______________________________________________
>> L2Ork-dev mailing list
>> L2Ork-dev at disis.music.vt.edu
>> http://disis.music.vt.edu/listinfo/l2ork-dev
>>
>
>
>
> --
> Dr. Albert Gr"af
> Computer Music Research Group, JGU Mainz, Germany
> Email: aggraef at gmail.com
> WWW: https://plus.google.com/+AlbertGraef
>
--
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email: aggraef at gmail.com
WWW: https://plus.google.com/+AlbertGraef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20161107/61da663a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: intelligent-patching.pd
Type: text/x-pd-l2ork
Size: 784 bytes
Desc: not available
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20161107/61da663a/attachment-0001.bin>
More information about the L2Ork-dev
mailing list