<p dir="ltr">All this makes perfect sense. The reason why I was asking is because I remember introducing a patch that is not currently a part of the regular PD but was proposed to change the way how select and route specifically deal with data types and I cannot recall whether this is a part of the change. So in other words I'm not sure if this was originally a regression or an architectural choice to make things more streamlined. The challenge's that in PD there are way too many objects that are overloaded with functionalities that seem like an afterthought rather than I genuinely separate object. The fact that the route can be used both as a route and a selector to me is something that is not and optimal approach. It is all too eminent of the idea that if something has been done long enough the wrong way it will be eventually seen as the right way which is not what I think is true at all. In other words I'm not so much questioning your patch as much as I'm questioning what has caused the inconsistency in the first place.</p>

<p dir="ltr">At any rate, let me search for that old patch and try to find out whether the things you have fixed are essentially reverting the patch in question and furthermore to study the rationale behind the change introduced by the patch.</p>

<div class="gmail_quote">On Oct 8, 2013 3:20 PM, "Albert Graef" <<a href="mailto:aggraef@gmail.com">aggraef@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Oct 8, 2013 at 5:08 PM, Ivica Ico Bukvic <<a href="mailto:ico.bukvic@gmail.com">ico.bukvic@gmail.com</a>> wrote:<br>
> Are all the other conditions still valid (as in other modes)? pd-l2ork's<br>
> route differs on a number of counts from vanilla route, although its<br>
> operation should remain consistent (apart from additional options).<br>
<br>
I tried all the examples in route-help.pd and its subpatches, and with<br>
my changes they all work as described in those help patches. This<br>
covers all the different uses. Don't take my word for it; try it for<br>
yourself. :) Specifically, have a look at the type_mode subpatch, this<br>
covers the cases where pd-l2ork currently does the wrong thing. If you<br>
click on the [89( and [float 7( messages in the type_mode subpatch, it<br>
should bang the second outlet of [route] (which it does) and also<br>
output the number in the corresponding number box (which it doesn't).<br>
A similar issue arises with the [symbol pie( message and the symbol<br>
selector. These issues are fixed by my proposed changeset.<br>
<br>
If you still don't believe me, just look at the code itself. Your code<br>
clearly does the wrong thing, it will always output a bang in response<br>
to a float or a symbol.<br>
<br>
Note that this isn't just some esoteric corner case. It's a real bug<br>
which actually breaks one of my patches that works fine with vanilla<br>
Pd and previously used to run fine with pd-l2ork, too.<br>
<br>
Albert<br>
<br>
--<br>
Dr. Albert Gr"af<br>
Dept. of Music-Informatics, University of Mainz, Germany<br>
Email:  <a href="mailto:aggraef@gmail.com">aggraef@gmail.com</a><br>
WWW:    <a href="https://plus.google.com/111193356966611167754" target="_blank">https://plus.google.com/111193356966611167754</a><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>