Hi Paul If you take a look at the iOS external sdk it is possible to use the LCObjectPost method to send a message to an object from any thread. What this means is probably 95% of the work has been done to implement this for desktop too and RunRev need to just put in a few more resources to finish it off. What I would suggest is you email support with a request that the sdk be implemented for desktop and tell them what you would do with it and that it would result in your purchase. If you plan to release your external in some form too then let them know because that obviously adds value to the product.
Cheers -- M E R Goulding Software development services mergExt - There's an external for that! On 14/08/2012, at 5:03 AM, "Paul D. DeRocco" <pdero...@ix.netcom.com> wrote: > I'm still using Rev 3.5, partly because I've been holding out until LC > includes direct support for MIDI. Has that happened yet? > > If not, did LC add (over Rev) any way for a separate thread (or an OS > callback) in an external to cause a message to be sent within LC? One could > never do this in Rev, but if one could, it would allow externals to properly > support MIDI input. > > MIDI output is easy in an external, because it's synchronous. But the only > way I was able to do MIDI input in Rev was to stuff it into a FIFO and then > use a timer message to check the FIFO. That's adequate for non-real-time > stuff, but not for receiving musical events. If there were a way for an > external to send a message, or cause a message to be sent, then that would > eliminate the need for polling. > > There is already a timer message facility, e.g., > > send <message> [to <stack>] in <time> > > which allows an asynchronous event (ultimately a timer interrupt inside the > kernel) to cause a message to be sent, it would seem to be fairly easy to > extend this to support signals, since Posix guarantees support for at least > eight real-time user-defined signals, and Windows can emulate them easily > enough with semaphores. For instance, > > send <message> [to <stack>] on signal <number> > > could express the same concept, but triggered by a signal rather than a > timer interrupt. I could then have my MIDI input callback stuff bytes into a > FIFO and generate a signal, and have LC use the signal to send a message > that reads whatever is in the FIFO. > > By the way, combining the two > > send <message> [to <stack>] on signal <number> or in <time> > > could express the concept of a time limit, where either the signal or the > timeout would cause the message to be sent, but not both. > > But those ideas are predicated on the assumption that LC hasn't dealt with > this issue yet. If it has, I'd like to know about it, and if it solves my > problem, upgrade to the latest version. > > -- > > Ciao, Paul D. DeRocco > Paul mailto:pdero...@ix.netcom.com > > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
