[L2Ork-dev] [t a] speedup

[Ivica Bukvic]

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.

Best,

Ico


-- 
Ivica Ico Bukvic, D.M.A.
Creative Technologies in Music
Director -- DISIS, L2Ork, CTM
ICAT Senior Fellow
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
ico at vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Thu, Apr 5, 2018, 16:20 Albert Graef <aggraef at gmail.com> wrote:

> I'm all for optimizations, especially if they come cheap, but are you
> sure that it's worth going through all that pain? It would be good to
> have some real figures about that trigger bottleneck before embarking
> on this. Also, I'd be wary of the potential quadratic blowup of
> (hidden) connections, this also comes at a cost which might just
> outweigh the gains in many cases.
>
> I'd start out by just adding a new "fan-out" object like "t" which
> just distributes its input to its outlets. That should certainly be an
> improvement, maybe that's already good enough, and at the very least
> you get a better idea about the performance gains that you might hope
> for with the full-blown solution.
>
> On Thu, Apr 5, 2018 at 8:36 PM, Jonathan Wilkes <jon.w.wilkes at gmail.com>
> wrote:
> > Hi list,
> >
> > I was looking at various ways to speed up trigger,
> > but none of them compare to this:
> >
> > 1. make a new class called "trigger_fast" with a constructor
> > of 0 (i.e., you can't create it by typing trigger_fast in an object box.
> >
> > 2. Inside trigger_new, check to see if all the arguments are
> > "anything" (or "a").
> >
> > 3. If all args are anythings, create a trigger_fast object instead of
> > a trigger object, and return its reference.
> >
> > 4. In the connection logic in g_editor.c, check if a new connection is
> > coming/going to a trigger_fast_class object.
> >
> > 5. If so, make the linked list graph bypass [t a] altogether and
> > connect into the correct objects above and below the trigger_fast
> > object as necessary to get the ordering specified by trigger's
> > one-to-many right-to-left semantics.
> >
> > 6. Draw the connections in the diagram as the user made them.
> >
> > 7. Have a debug mode or toggle to show the connections as they are in
> > the linked list vs as the user made them.
> >
> > This is probably a pain to implement, but it would have the following
> benefits:
> >
> > * encourage users to use [t a] and ignore the complicated trigger args
> > which have inconsistent behavior and most of the time just cause
> > confusion
> > * get a big performance increase on _all_ platforms _regardless_ of
> > the c compiler used as users employ [t a] more often
> > * be completely backwards compatible with whatever the current
> > behavior of trigger is for the other args and arg combinations.
> >
> > That would cover all use cases except [t b] and mixtures of [t b a].
> > But I think it still covers a lot of cases.
> >
> > -Jonathan
> > _______________________________________________
> > L2Ork-dev mailing list
> > L2Ork-dev at disis.music.vt.edu
> > https://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
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20180405/29acc1a3/attachment-0001.html>