[L2Ork-dev] Description of intelligent patching
Albert Graef
aggraef at gmail.com
Mon Nov 7 11:16:42 UTC 2016
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20161107/66259613/attachment.html>
More information about the L2Ork-dev
mailing list