<p dir="ltr">The iemgui object positioning was a conscious decision to ensure objects autopatch and are positioned properly. In other words in vanilla/extended they are not positioned according to their xy position and this is a bug they don't want to fix due to backwards compatibility. We are looking possibly into creating a compatibility flag that would support this buggy legacy behaviour but honestly it is not very high on my priority list because preferred way would be vanilla and extended fixing the problem which is clearly a bug.</p>
<p dir="ltr">As for the first bug report, this one is kind of tricky because when you do ctrl+1 and type vsl, that object's height is technically that of a default object and the autopatching is attempted before vsl is fully instantiated and its height properly set. Let me see if I can think of a way to test this.</p>
<p dir="ltr">The most obvious solution is not to type vsl into the object box and instead create vertical slider and other gui objects using their keyboard shortcuts, e.g. for vsl (as shown in the Put menu) you would type shift+ctrl+v.</p>
<p dir="ltr">HTH</p>
<div class="gmail_quote">On Sep 19, 2014 9:39 AM, "Gilberto Agostinho" <<a href="mailto:gilbertohasnofb@googlemail.com">gilbertohasnofb@googlemail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hello all,<br>
<br>
I discovered some problems with the placement of sliders due to
autopatch:<br>
<br>
- Using only the keyboard to input a patck (autopatch), the
following sequence Ctrl+2, 64, Ctrl+1, vsl, Ctrl+3 results into:
<a href="http://s13.postimg.org/rgyspkdfr/image.png" target="_blank">http://s13.postimg.org/rgyspkdfr/image.png</a><br>
- but if one types: Ctrl+2, 64, Ctrl+1, vsl and now deselect the
[vsl] object and then select it again, and then type Ctrl+3, we get
the expected result: <a href="http://s27.postimg.org/y146zhcs3/image.png" target="_blank">http://s27.postimg.org/y146zhcs3/image.png</a><br>
<br>
- The same is not true for [hsl], which outputs a beautiful result
straight away: <a href="http://s30.postimg.org/4pkzkopkh/image.png" target="_blank">http://s30.postimg.org/4pkzkopkh/image.png</a><br>
- The problem here is compatibility: pd-extended's [hsl] is anchored
to the left of pd-l2Ork one. Have a look on the same file as above,
but opened in pd-extended:
<a href="http://s28.postimg.org/dkvm4fylp/image.png" target="_blank">http://s28.postimg.org/dkvm4fylp/image.png</a><br>
- This is probably because you tried to fix the odd behaviour of
pd-extended's autopath positioning of [hsl]. In pd-extended, if we
try Ctrl+2, 64, Ctrl+1, hsl, Ctrl+3, we get:
<a href="http://s7.postimg.org/b48zw71y3/image.png" target="_blank">http://s7.postimg.org/b48zw71y3/image.png</a><br>
- And similarly to the [vsl] case described above, if we try Ctrl+2,
64, Ctrl+1, hsl, then deselect and select the [hsl] object again
before typing Ctrl+3, we get:
<a href="http://s9.postimg.org/46vkft1xb/image.png" target="_blank">http://s9.postimg.org/46vkft1xb/image.png</a><br>
<br>
Ideally, the best way of solving this would be to correct
pd-extended (and vanilla as well if it shows the same behaviour),
else the layout of patches will not be completely compatible between
both programs. Imagine someone took a long time creating a pretty
GUI with sliders, radios and colored canvas in one program, just to
open it in the other one and finding the sliders out of place.<br>
<br>
Let me know if you wish me to do any more tests involving this
issue.<br>
<br>
Best,<br>
Gilberto
<div>
<div title="Click to translate"></div>
</div>
</div>
<br>_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="http://disis.music.vt.edu/listinfo/l2ork-dev" target="_blank">http://disis.music.vt.edu/listinfo/l2ork-dev</a><br></blockquote></div>