Regarding lack of comments, I think this can be traced back to Apple. They
actively encourage the self-documenting code school of thought, where function
and variable names are supposed to make it obvious what the code is doing.
The argument against extensive comments is that they can get out
From: Mark Wilcox
Specific to your proposal, if the semaphores are to be
created by the external then possibly a semaphore itself is
unnecessarily over-specified - unless you were planning to
contribute an implementation, in which case the engine
contributors board is probably the best
Paul-
I ran into the same thing some years ago trying to implement MIDI
externals. Even with MIDI output when you're dealing with polyphonic
streams to multiple devices, I found it was easier to have LC do
things than to try to keep track of multiple threads in externals.
But things are looking
Paul - sorry, didn't mean to jump all over your suggestion. It was something I
was already thinking about and I was just trying to say it's so important an
area that we really need to do more than the minimum possible to enable async
responses. However, as Mark has kindly pointed out, we're
From: m_p_wil...@yahoo.co.uk
Paul - sorry, didn't mean to jump all over your suggestion.
It was something I was already thinking about and I was just
trying to say it's so important an area that we really need
to do more than the minimum possible to enable async
responses. However, as
-Original Message-
From: Monte Goulding
That's the iOS sdk which I expect will be the basis for the
extensions api. It is documented.
So are you saying that outside of iOS, there's nothing but the same old
external interface, but that it is likely that the iOS SDK will be
Paul-
Sunday, April 21, 2013, 8:11:08 PM, you wrote:
So are you saying that outside of iOS, there's nothing but the same old
external interface, but that it is likely that the iOS SDK will be
generalized to the other platforms in the future?
That. Very that. It was promised and teased at a
