• 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: On Memory Management & MusicSequence
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On Memory Management & MusicSequence


  • Subject: Re: On Memory Management & MusicSequence
  • From: William Stewart <email@hidden>
  • Date: Tue, 10 Feb 2004 15:45:50 -0800

On 09/02/2004, at 4:34 PM, Daniel Jalkut wrote:

Thanks, Bill. So the sequence doesn't take ownership of the AUGraph (or whatever target) it's aimed at. Is it safe to assume in general that "setter" type APIs don't take ownership? I was hoping for some kind of genera rule of thumb to keep things sane. I assume that things like "AUGraphCreateNode

You list "remove the graph from the sequence" as one of the steps to do before disposing of the graph, but as far as I can tell the only way to do this is to replace it with another graph (SetAUGraph again). So what do I pass if I want to clean up properly without setting a new graph in its place? Can I pass NULL to SetAUGraph? Same question for SetMIDIEndpoint ?

no - we don't have a concept of a sequence without a graph.. also, why would you want to keep making and throwing away graphs? You can change their connections, etc, on the fly?

It turns out my worst bug was in fact a "didn't stop playing the sequence" bug. To anybody who's reading this before venturing into MusicPlayer - always stop playing the sequence! Crazy stuff will happen to the new AUGraph if you try to switch the AUGraph before stopping.

Yes indeed... This maybe a restriction we should relax, but at this point the sequence player has to build up a fairly sophisticated knowledge of the graph, the nodes it is addressing, etc, before it starts playing. Once that is established, changing the underlying state (both the sequence -> node/endpoint targetting, as well as the underlying graph) will *not* work - its not that dynamic. However, this restriction can be fairly easily worked-around... if you at least have a knowledge of the tracks/nodes you intend to work with. You can mute/unmute a track, you can connect/disconnect nodes, etc... so there is a fair degree of dynamic state that can be changed.

Bill


Thanks again,
Daniel

On Feb 9, 2004, at 12:42 PM, William Stewart wrote:

You better not dispose of a graph that is in use by a sequence. So, you'd have to:
Stop playing the sequence
remove the sequence from the player (if you're disposing the graph, its sequence is unplayable)
Remove the graph from the sequence
dispose the graph


-- mailto:email@hidden
tel: +1 408 974 4056

________________________________________________________________________ __
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________ __
_______________________________________________
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.
References: 
 >On Memory Management & MusicSequence (From: Daniel Jalkut <email@hidden>)
 >Re: On Memory Management & MusicSequence (From: William Stewart <email@hidden>)
 >Re: On Memory Management & MusicSequence (From: Daniel Jalkut <email@hidden>)

  • Prev by Date: Re: Channel Maps and HALOutputUnit
  • Next by Date: Re: efficient device channel enabling - was Re: fIsMixable
  • Previous by thread: Re: On Memory Management & MusicSequence
  • Next by thread: Playing AudioBuffers from Memory
  • Index(es):
    • Date
    • Thread