How to Dynamically Create Nodes?

[cdigit]

I want to create a very simple multitrack recorder where after recording one sound to disk, I would like to record n additional sounds to disk and be able to play all of them back.
My setup uses these features tied together:

• device
• engine
• resource manager
• node graph

I load sounds via the resource manager, which needs a ma_resource_manager_data_source object, then I create a node which needs a ma_data_source_node and a ma_resource_manager_data_source object.

How can I make multiple instances of these objects without knowing how many I will need ahead of time?
Should I declare a set number of data_source and source_node objects and manage their use, or is there some way to make these objects in an ad hoc fashion?
I suppose I could also make arrays of data_source and source_node and keep track of them with pointers? Just wondering if any of this makes sense.

[mackron]

First of all, are you aware that ma_engine already encapsulates a device, resource manager and node graph? Just thought I'd mention that in case you're other-complicating your architecture. Typically you would only use your own self-managed objects if you have very specific requirements.

The engine will create it's own device and resource manager internally by default unless you tell it not to by specifying your own objects in the device config. For the node graph, the engine is a node graph (ma_sound and ma_sound_group are nodes). These are the functions you can use to get the relevant objects:

ma_engine_get_device()
ma_engine_get_resource_manager()
ma_engine_get_node_graph()

Also, the ma_sound object encapsulates the ma_resource_manager_data_source and ma_node stuff for you.

With that out of the road, back to your main question. Do you mean you want a cache your objects and only initialize them when you need to? If so, this is just standard buffer management - just preallocate some memory for your objects and initialize them as necessary. Just make sure their address remains the same for their entire lifetime. To be honest, as a starting point just to get everything working at a basic level, I would just heap-allocate each individual object as needed and then once you've got it functional, then move on to optimizing.

[orcmid]

Adding to the @Makron explanation. You could construct an array of (pointers) that you fill in as you allocate the kind of object the array is pointers of. If the allocated size of the array is getting too full, just allocate a bigger one next time. The objects are allocated dynamically, and their pointers are added into the array in consecutive entries.

This only works if there is no particular discrimination among the different objects.

Alternatively, you could thread linked lists through them, though that might not be so handy in terms of finding particular ones.

Without knowing more about the actual situation, this is all just shooting from the hip.

[cdigit]

First of all, are you aware that ma_engine already encapsulates a device, resource manager and node graph?

Thank you, yes, I'm aware, I split them all out thinking it will give the most flexibility and to learn how they work together. I will most likely refactor what I have for simplicity and let the engine do everything on it's on. Bear with me, I'm writing this in a style to help me think through it while researching stuff...

Do you mean you want a cache your objects and only initialize them when you need to? If so, this is just standard buffer management - just preallocate some memory for your objects and initialize them as necessary. ...I would just heap-allocate each individual object as needed and then once you've got it functional, then move on to optimizing.

Not so much caching but being able to create objects while the program is running. The workflow would be like:

1. start app
2. hit record [file is written to disk]
3. hit stop (rewinds a global engine timer to initial starting point)
   app loads newly created file into an ma_sound
4. hit play
   play the ma_sound
5. hit stop

To get this to work with one sound, I would have to have an ma_sound already declared before runtime: ma_sound sound; Cool.
Now, if I'm running the program and I want to hit record say 10 times, it would not work after the first record session because I only have one ma_sound declared. So what I would want is that every time I hit record, a new ma_sound is allocated and when recording is complete (stop), I can initialize/load the new file into the new ma_sound for playback. When playing, it will playback all the previously recorded ma_sounds. Something like this:

// app is running
// start recording, then stop
// declare an ma_sound for new recorded file
ma_sound sound_1;
// start recording, then stop
ma_sound sound_2;
...
ma_sound sound_10;

As far as I know I can't just declare objects at runtime. Not sure how to create ma_sounds when the app is running. When you say preallocating memory, I'm thinking that an empty chunk of memory is marked for use and now I need to use, but how can I initialize an ma_sound to use a specific chunk of memory. This is most likely my lack of understanding of C. In scripting languages, I would have a function that could be called many times and looks something like this:

recordSound(array_of_recordings){
   // declare a new ma_sound;
    ma_sound sound = new ma_sound();
    // init the sound, load recorded file into it. 
    // add the sound into a list of recordings
     array_of_recordings.push(sound);
}

I understand that malloc will allocate space on the heap, but I need to control what goes into it?
OK
I used malloc before to create empty space to store buffer data using a void pointer, so I wasn't thinking about using a pointer to a real object. This worked in a function call while the app was running!

    ma_sound *pma_sound;
    pma_sound = malloc(sizeof(ma_sound));
    result = ma_sound_init_from_file(g_engine, filePath, 0, NULL, NULL, pma_sound);
    ma_sound_start(pma_sound);

I think this is what you meant when you said just to heap allocate them individually and then optimize them later (which I think would involve allocating one big chunk and then keeping track of where the ma_sounds are located in the memory)

At the end of the day:
It is possible to dynamically allocate and initialize ma_sound without declaring them all up front statically.

[cdigit]

Adding to the @Makron explanation. You could construct an array of (pointers) that you fill in as you allocate the kind of object the array is pointers of. If the allocated size of the array is getting too full, just allocate a bigger one next time. The objects are allocated dynamically, and their pointers are added into the array in consecutive entries.

This only works if there is no particular discrimination among the different objects.

Alternatively, you could thread linked lists through them, though that might not be so handy in terms of finding particular ones.

Without knowing more about the actual situation, this is all just shooting from the hip.

Thanks, It's good to know that this is sensible direction. I was thinking about using arrays to hold pointers to the ma_sounds but didn't understand how to do it during runtime and was wondering if it was possible with the library. I've found some info about dynamic allocation to study up on and can now see it's possible and indeed works.

[mackron]

What you're asking is more of a general C programming thing than a miniaudio thing.

Your last code snippet is correct for what you're trying to do. miniaudio requires you to allocate and manage the memory of all of your objects yourself. Your job is to make sure that memory stays allocated for the life of your objects, and that the address of the object never changes. This is actually just standard old memory management and can be solved most generally with a malloc():

ma_sound* pSound = (ma_sound*)malloc(sizeof(ma_sound));

After the allocation you just call ma_sound_init_*() and pass in your pointer that you just allocated. That's a solution to your question:

It is possible to dynamically allocate and initialize ma_sound without declaring them all up front statically.

Of course, that's a very basic solution, and it'll work just fine (just remember to free the memory when you're done with the object!). That's what I meant when I said to just allocate each object on the heap. You can of course optimize your memory management strategy to suit your requirements, but first things first, just get the simple implementation working and then go from there.

You've probably seen the examples where I declare the objects on the stack. Don't get too hung up on that - that's just declaring the ma_sound structure on the stack rather than the heap (malloc()) because it works well for the example and keeps the code clean. You don't have to declare your objects exactly like in the examples.