<div dir="ltr">Forgot to attach the test patch, here it is.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 7, 2016 at 12:16 PM, Albert Graef <span dir="ltr"><<a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>Hi Ico,<br><br></div>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.<br><br>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...<br></div><br></div>Also, I can make the fourth option crash pd-l2ork with a segfault. To reproduce:<br><br>(1) launch the attached intelligent-patching.pd patch<br><br>(2) select all 4 pack/unpack objects in the patch<br><br>(3) connect outlet #3 of the left pack object with inlet #1 of the right unpack object<br><br>=> pd-l2ork crashes with SIGSEGV, gdb backtrace:<br><br>#0 0x0000000000499c00 in outconnect_setvisible ()<br>#1 0x000000000047788e in canvas_doconnect_doit ()<br>#2 0x0000000000478778 in canvas_trymulticonnect ()<br>#3 0x0000000000478825 in canvas_doconnect ()<br>#4 0x0000000000481f09 in canvas_mouseup ()<br>#5 0x000000000049890d in pd_typedmess ()<br>#6 0x000000000049862a in pd_typedmess ()<br>#7 0x00000000004a13f6 in binbuf_eval ()<br>#8 0x00000000004a80cc in socketreceiver_read ()<br>#9 0x00000000004a740b in ?? ()<br>#10 0x00000000004a4556 in m_mainloop ()<br>#11 0x00000000004a6e28 in sys_main ()<br>#12 0x00007ffff63ba291 in __libc_start_main () from /usr/lib/libc.so.6<br>#13 0x00000000004174da in _start ()<br><br>purr-data does exactly the same, but its gdb backtrace is a little more informative, so I'm attaching that as well:<br><br>#0 outconnect_setvisible (oc=oc@entry=0x0, vis=vis@entry=1) at m_obj.c:349<br>#1 0x00000000004733de in canvas_doconnect_doit (x=x@entry=0x2a50c00, <br> y1=0x2a4f1b0, y2=y2@entry=0x2a55cb0, closest1=closest1@entry=2, <br> closest2=closest2@entry=1, multi=multi@entry=1, create_undo=1)<br> at g_editor.c:4024<br>#2 0x00000000004742b8 in canvas_trymulticonnect (x=x@entry=0x2a50c00, <br> xpos=xpos@entry=169, ypos=ypos@entry=98, which=which@entry=1, <br> doit=doit@entry=1) at g_editor.c:4499<br>#3 0x0000000000474365 in canvas_doconnect (x=x@entry=0x2a50c00, <br> xpos=xpos@entry=169, ypos=ypos@entry=98, which=which@entry=1, <br> doit=doit@entry=1) at g_editor.c:4521<br>#4 0x000000000047dab9 in canvas_mouseup (x=0x2a50c00, fxpos=<optimized out>, <br> fypos=<optimized out>, fwhich=1) at g_editor.c:4719<br>#5 0x00000000004941dd in pd_typedmess (x=0x2a50c00, s=0xb7efa0, <br> argc=<optimized out>, argv=<optimized out>) at m_class.c:864<br>#6 0x0000000000493efa in pd_typedmess (x=x@entry=0x2a59000, s=0xb7efa0, <br> argc=argc@entry=3, argv=argv@entry=<wbr>0x7fffffffe370) at m_class.c:886<br>#7 0x000000000049cd16 in binbuf_eval (x=<optimized out>, target=0x2a59000, <br> target@entry=0x0, argc=argc@entry=0, argv=argv@entry=0x0) at m_binbuf.c:904<br>#8 0x00000000004a393c in socketreceiver_read (x=0xc79d60, fd=28)<br> at s_inter.c:568<br>#9 0x00000000004a2c7b in sys_domicrosleep (microsec=<optimized out>, pollem=1)<br> at s_inter.c:206<br>#10 0x00000000004a2d25 in sys_microsleep (microsec=<optimized out>)<br> at s_inter.c:228<br>#11 0x000000000049fe56 in m_pollingscheduler () at m_sched.c:562<br>#12 m_mainloop () at m_sched.c:622<br>#13 0x00000000004a26e8 in sys_main (argc=<optimized out>, argv=<optimized out>)<br> at s_main.c:335<br>#14 0x00007ffff63ba291 in __libc_start_main () from /usr/lib/libc.so.6<br>#15 0x0000000000417d7a in _start ()<br><br></div>I haven't had time to look into the code yet, but will do asap if noone beats me to it. :)<br><br><div>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?<br></div><br></div>Cheers,<br></div>Albert<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 7, 2016 at 10:03 AM, Ivica Ico Bukvic <span dir="ltr"><<a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
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:<br>
<br>
/* FIRST OPTION: if two objects are selected and the one
that is<br>
originating is one of the selected objects try
multi-connecting<br>
all outlets into all inlets starting with the user-made
one as<br>
an offset */<br>
<br>
/* SECOND OPTION: if two or more objects are selected and
the one<br>
that is originating is not one of the selected, connect
originating<br>
to all selected objects' the outlets specified by the
first<br>
connection */<br>
<br>
/* THIRD OPTION: if two or more objects are selected and the
one<br>
that is receiving connection is one of the selected, and
the<br>
target object is selected, connect nth outlet (as
specified by<br>
the first connection) from all selected objects into the
inlet<br>
of the unselected one */<br>
<br>
/* FOURTH OPTION: if more than two objects are selected and
both y1<br>
and y2 are selected connect each originating object's
outlet to<br>
each of the outgoing objects' inlets until you run out of
objects<br>
or outlets. This one is tricky as there is no guarrantee
that<br>
objects will be selected in proper visual order, so we
order the<br>
selection from left to right and top to bottom to ensure
proper<br>
visual pairing. This option has two variants, A and B.<br>
OPTION A VS B: we either connect outgoing to each of
other objects<br>
(A) or incoming to all other objects (B). We determine
which one of<br>
the two options is selected based on which condition will
yield more<br>
successful connections. */<br>
<br>
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<br>
<br>
Best,<br>
<br>
Ico<div><div class="m_3080190777915496036h5"><br>
<br>
<div class="m_3080190777915496036m_-7489027994614454525moz-cite-prefix">On 11/6/2016 6:45 PM, Albert Graef
wrote:<br>
</div>
</div></div><blockquote type="cite"><div><div class="m_3080190777915496036h5">
<div dir="ltr">
<div>
<div>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.<br>
<br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
TIA,<br>
</div>
Albert<br clear="all">
<div>
<div>
<div><br>
-- <br>
<div class="m_3080190777915496036m_-7489027994614454525gmail_signature">
<div dir="ltr">Dr. Albert Gr"af<br>
Computer Music Research Group, JGU Mainz, Germany<br>
Email: <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a><br>
WWW: <a href="https://plus.google.com/+AlbertGraef" target="_blank">https://plus.google.com/+Albe<wbr>rtGraef</a></div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="m_3080190777915496036m_-7489027994614454525mimeAttachmentHeader"></fieldset>
<br>
</div></div><pre>______________________________<wbr>_________________
L2Ork-dev mailing list
<a class="m_3080190777915496036m_-7489027994614454525moz-txt-link-abbreviated" href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a>
<a class="m_3080190777915496036m_-7489027994614454525moz-txt-link-freetext" href="http://disis.music.vt.edu/listinfo/l2ork-dev" target="_blank">http://disis.music.vt.edu/list<wbr>info/l2ork-dev</a></pre>
</blockquote>
<br>
</div>
<br>______________________________<wbr>_________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="http://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">http://disis.music.vt.edu/list<wbr>info/l2ork-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="m_3080190777915496036gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Dr. Albert Gr"af<br>Computer Music Research Group, JGU Mainz, Germany<br>Email: <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a><br>WWW: <a href="https://plus.google.com/+AlbertGraef" target="_blank">https://plus.google.com/+<wbr>AlbertGraef</a></div></div>
</div>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Dr. Albert Gr"af<br>Computer Music Research Group, JGU Mainz, Germany<br>Email: <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a><br>WWW: <a href="https://plus.google.com/+AlbertGraef" target="_blank">https://plus.google.com/+AlbertGraef</a></div></div>
</div>