• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: AU MIDI events scheduled beyond next rendering slice
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AU MIDI events scheduled beyond next rendering slice


  • Subject: Re: AU MIDI events scheduled beyond next rendering slice
  • From: Urs Heckmann <email@hidden>
  • Date: Thu, 7 Aug 2003 10:13:16 +0200

Am Donnerstag, 07.08.03, um 02:11 Uhr (Europe/Berlin) schrieb Jeremy Sagan:

Urs,

I think you are misunderstanding me. I will try to clarify.

Yeah. Sorry.

My personal opinion, from a host perspective, is that I agree. This should not happen. It is the hosts job to do scheduling.

Hosts can't queue into a running render process...

<snip>

I am not sure what you are responding to here. I was just trying to write what Bill eventually wrote more eloquently "But (and the documentation is I think clear on this), the frame offsets are always described as being offsets into the NEXT slice of audio that is to be rendered (and for ramped parameters, they are rescheduled for each slice),..." Thus the AU only needs to keep track of one buffer full of data for MIDI events.

Ooops, oh well, 2nd language problem, I guess. I already read Marc's "scheduling of midi" as sort of the stuff I was working on during the last 3 days. - Of course, the host has to do scheduling properly.

However - and I'm responding/disagreeing to the consensus about the "next buffer only" thing - I think some future knowledge is fine as well. - If there was a limit to the offset, like 2x ProcessBufferSize, some things could be done easier.

Imagine I would want NoteOns at least 128 samples in advance, for some future vision. The 128 samples could be used to more economically steal voices without clicks, to easier prepare an "inner queue", and a whole lotta nice stuff as well.

For that, I would usually set the plugs latency to 128 samples, so I simply add 128 to each timestamp and process without latency. That would hopefully do the trick, but it would screw up timing for live play.

I would feel perfectly well if we had a EventsCome_PreferredlyWithFutureVisionIntoNextBuffer that could be set to a preferred look ahead. Still, timestamps could be zero for live play, but for play back, they'd always come some samples ahead of time, hence with timestamps >= n < (Buffersize + n). Could save a lot of cpu cycles for Music Devices.

Hmm, I have seen NoteOn/Off combos at same time quite often now, in several hosts. What are they for, from the perspective of a host designer?

If you are asking about a note that has 0 duration then I do not know. Otherwise this is usually due to step recording. If there is a note with duration 100 and is back to back with another note that begins at time 100 then you will see, at time 100, a note-on and a note-off and they could, of course, be the same pitch.

Okay, in that case I'm fine. There would already be and instance of the NoteOn, hence the NoteOff would be assigned to that, regardless if a subsequent NoteOn comes in before or after it for the same sample.

However, I've also seen those combos with zero length when there hasn't been that note before (I'm not referring to any host in particular, it could have been my external sequencer as well).

And I agree with DLS, sending a NoteOff _before_ a corresponding NoteOn is completely messy. Any NoteOff I get that is not for a NoteOn I already have, will immediately be trashed. Otherwise I will need a really, really long queue (capable of holding 2048 NoteOffs + some extra for thread safety + a HUGE, really, really HUGE scanning overhead)...
I think you are misunderstanding my initial email. I agree there is no reason to send a note-off before a note-on but as I mentioned above there is a perfectly valid scenario where a note-off and a note-on can occur at the same time. In that case if the note-on appears to the DLS AU before the note-off (remember this is even though the time stamps are the same) it causes the DLS to not play the note-on.

Yes. My misunderstanding was, I thought you mean a very short Note happening over zero samples, while you imply a valid note off for another note. If it's valid, then it's okay.

However, even if a note lasts 20 samples only, I hope the NoteOff will always be scheduled _after_ the NoteOn 8-)

Cheers,

;) Urs
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: AU MIDI events scheduled beyond next rendering slice
      • From: Bill Stewart <email@hidden>
References: 
 >Re: AU MIDI events scheduled beyond next rendering slice (From: Jeremy Sagan <email@hidden>)

  • Prev by Date: Re: AU MIDI events scheduled beyond next rendering slice
  • Next by Date: How to use AudioHardwareGetProperty
  • Previous by thread: Re: AU MIDI events scheduled beyond next rendering slice
  • Next by thread: Re: AU MIDI events scheduled beyond next rendering slice
  • Index(es):
    • Date
    • Thread