Seeking general guidance


#1

…from all you smart people!

As mentioned in an earlier post, I’m porting… well rewriting an old sequencing tool under Juce.

Back in the olden days (apple ii & old mac), I did all my MIDI output at interrupt level, to a heartbeat of 1ms. Makes coding easy. Various tricks to catch up if you take too long somewhere. Also, carefully only redraw parts of the screen that have changed, running beat-numbers and such.

Now, my question. Here in the modern world, of 2009, Juce, &c, I think we do this: Set a timer to get infrequent and irregular pulses (20ms, +/- 10, or more). At that time, we queue events into a MIDI buffer, offset from Time::getMillisecondCounter(). Hopefully we get called often enough to just “top off” the queue, into, say, 50ms into the future. Or so.

Q1: Is that the general strategy to use?

Then, call midiOutput::sendBlockOfMessages(). “The time must be in the future”.

Q2: If, due to dilly-dallying, the time is a millisecond into the past, will all the events still come out?

Q3: Is there a way to immediately draw only part of the screen? Or do we just inval certain areas, and use Component bounds and granularity to optimize the drawing? (Or do we just draw everything, all the time, because modern computers can draw pixels so well?)

Thanks for any guidance! Cheers.


#2

On Windows I use a Multimedia timer that fires once every ms. On the mac, I use a realtime thread and mach_wait_until to sleep for one ms.

Then once a ms, I look in my queue, and find any messages that need to be sent and fire them out.

As for drawing, I invalidate as little as possible and only if it has actually changed.

Also, if possible, I use setBufferedToImage(true) and setOpaque(true)


#3

Thanks, G-Mon, that is useful.

Is mach-wait-until accurate in that usage? That is, not drifting based on how much work is done while the tread is active, each ms?

Thanks! ==> d