<div dir="auto">Not to steal this thread, we may have a much bigger fish to fry. Namely, we still don't have a graceful handling of anything but 16 bit wav files in certain situations, particularly when we're trying to extract the sound file properties. It seems to me supporting all file formats, or at least as many as we can through libsndfile or some other third-party library is in my opinion a much higher priority.<div dir="auto"><br></div><div dir="auto">Best,</div><div dir="auto"><br></div><div dir="auto">Ico</div><div dir="auto"><br><div data-smartmail="gmail_signature" dir="auto"><br>-- <br>Ivica Ico Bukvic, D.M.A.<br>Creative Technologies in Music<br>Director -- DISIS, L2Ork, CTM<br>ICAT Senior Fellow<br>Virginia Tech<br>School of Performing Arts – 0141<br>Blacksburg, VA 24061<br>(540) 231-6139<br><a href="mailto:ico@vt.edu">ico@vt.edu</a><br><a href="http://www.performingarts.vt.edu">www.performingarts.vt.edu</a><br><a href="http://disis.icat.vt.edu">disis.icat.vt.edu</a><br><a href="http://l2ork.icat.vt.edu">l2ork.icat.vt.edu</a><br><a href="http://ico.bukvic.net">ico.bukvic.net</a></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Apr 5, 2018, 16:20 Albert Graef <<a href="mailto:aggraef@gmail.com">aggraef@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm all for optimizations, especially if they come cheap, but are you<br>
sure that it's worth going through all that pain? It would be good to<br>
have some real figures about that trigger bottleneck before embarking<br>
on this. Also, I'd be wary of the potential quadratic blowup of<br>
(hidden) connections, this also comes at a cost which might just<br>
outweigh the gains in many cases.<br>
<br>
I'd start out by just adding a new "fan-out" object like "t" which<br>
just distributes its input to its outlets. That should certainly be an<br>
improvement, maybe that's already good enough, and at the very least<br>
you get a better idea about the performance gains that you might hope<br>
for with the full-blown solution.<br>
<br>
On Thu, Apr 5, 2018 at 8:36 PM, Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank" rel="noreferrer">jon.w.wilkes@gmail.com</a>> wrote:<br>
> Hi list,<br>
><br>
> I was looking at various ways to speed up trigger,<br>
> but none of them compare to this:<br>
><br>
> 1. make a new class called "trigger_fast" with a constructor<br>
> of 0 (i.e., you can't create it by typing trigger_fast in an object box.<br>
><br>
> 2. Inside trigger_new, check to see if all the arguments are<br>
> "anything" (or "a").<br>
><br>
> 3. If all args are anythings, create a trigger_fast object instead of<br>
> a trigger object, and return its reference.<br>
><br>
> 4. In the connection logic in g_editor.c, check if a new connection is<br>
> coming/going to a trigger_fast_class object.<br>
><br>
> 5. If so, make the linked list graph bypass [t a] altogether and<br>
> connect into the correct objects above and below the trigger_fast<br>
> object as necessary to get the ordering specified by trigger's<br>
> one-to-many right-to-left semantics.<br>
><br>
> 6. Draw the connections in the diagram as the user made them.<br>
><br>
> 7. Have a debug mode or toggle to show the connections as they are in<br>
> the linked list vs as the user made them.<br>
><br>
> This is probably a pain to implement, but it would have the following benefits:<br>
><br>
> * encourage users to use [t a] and ignore the complicated trigger args<br>
> which have inconsistent behavior and most of the time just cause<br>
> confusion<br>
> * get a big performance increase on _all_ platforms _regardless_ of<br>
> the c compiler used as users employ [t a] more often<br>
> * be completely backwards compatible with whatever the current<br>
> behavior of trigger is for the other args and arg combinations.<br>
><br>
> That would cover all use cases except [t b] and mixtures of [t b a].<br>
> But I think it still covers a lot of cases.<br>
><br>
> -Jonathan<br>
> _______________________________________________<br>
> L2Ork-dev mailing list<br>
> <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank" rel="noreferrer">L2Ork-dev@disis.music.vt.edu</a><br>
> <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
<br>
<br>
<br>
--<br>
Dr. Albert Gr"af<br>
Computer Music Research Group, JGU Mainz, Germany<br>
Email:  <a href="mailto:aggraef@gmail.com" target="_blank" rel="noreferrer">aggraef@gmail.com</a><br>
WWW:    <a href="https://plus.google.com/+AlbertGraef" rel="noreferrer noreferrer" target="_blank">https://plus.google.com/+AlbertGraef</a><br>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank" rel="noreferrer">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div>