LÖVE

I thought like that too before, and raidho implemented it like that at first, as well... but there were issues with it, i think.

Dr. Peeps wrote:

LÖVE 0.11 wrote:getData removes currently recorded samples from input and puts them into new SoundData

This works well, but .... What is the likelihood of having a variant of getData that doesn't create a new SoundData object with every call, instead "refilling" an existing buffer with new data?

If old SoundData is not exactly identical parameter-wise to would-be new SoundData, it has to be re-allocated entirely, at which point it's computationally cheaper to delete it from memory and produce new one from scratch, also not managing memory manually is one less headache for the user. It also eliminates possible problems with pointers to SoundData's data becoming invalid and causing segfault crashes if FFI attempts to use them.

0.11 also has a new Object:release method, which immediately decreases an Object's internal reference count and prevents it from being used in Lua after that. If there are no more internal references to that object (in love's C++ code or in another love thread), the object will be cleaned up and deallocated immediately.

This will help to keep consistent performance in the case where you're creating and throwing away objects.

slime wrote:0.11 also has a new Object:release method, which immediately decreases an Object's internal reference count and prevents it from being used in Lua after that. If there are no more internal references to that object (in love's C++ code or in another love thread), the object will be cleaned up and deallocated immediately.

This will help to keep consistent performance in the case where you're creating and throwing away objects.

Let's say that in love.update, i call the function to dump recorded data into a sounddata, i push that onto a qsource, then i nil the sounddata. When should i call the object:release, if i should at all? before or after nilling? Should i even nil the variable? Can manually calling :release introduce issues with automatic ref. count decreases (not counting cases where you actually want to keep objects around, only for one-shot objects, like in the above example)

zorg wrote:When should i call the object:release, if i should at all? before or after nilling?

Before. You won't have access to it after setting the variable to nil

zorg wrote:Should i even nil the variable?

Sure, since it makes it more explicit in your code that the object is no longer usable.

zorg wrote:Can manually calling :release introduce issues with automatic ref. count decreases (not counting cases where you actually want to keep objects around, only for one-shot objects, like in the above example)

Nope. It basically just performs the release operation that normally happens when the Lua reference to the object is garbage-collected, and then prevents you from using the Lua reference to the object by causing an error if you try. It won't do the release operation again when the Lua reference to the object is actually garbage collected, so it won't cause any issues.

Excellent, slime. I just tested this idea by changing the example code from:
to:
And now the pointer to the data just sits at the same location. Problem solved, I guess! Thanks.

And I agree with everything you said, raidho. I don't want to muck up the simplicity of LÖVE. I also don't want to have to call object:release() all the time, but this is hopefully a special case.

It sits in the same location because you delete an object and immediately create another very similar in size one, and because your memory isn't fragmented. Don't expect that behavior to hold with complex projects with a lot of memory activity going on.

You indeed don't need to call this function if you don't feel like it, garbage collector does exactly that anyway. One big purpose of this function is to release large chunk of memory the data occupies immediately, without waiting on garbage collector to do it. This saves memory, and if you rapidly create many data objects then it also saves on garbage collector performance, as these objects are never converted to garbage and therefore don't contribute to garbage collector payload.

Jasoco wrote:So what exactly can you do with microphone support in Löve? It's not like you can process voice commands in real-time.

Maybe emulate the Famicom to kill rabbit enemies in a Zelda game or stuff the DS, 3DS and Wii U do in some games?

Realtime intercom, if I'd say.

buckle2000 wrote:

Jasoco wrote:So what exactly can you do with microphone support in Löve? It's not like you can process voice commands in real-time.

Maybe emulate the Famicom to kill rabbit enemies in a Zelda game or stuff the DS, 3DS and Wii U do in some games?

Realtime intercom, if I'd say.

Actually, to some degree, you can process voice commands in realtime.

I mean, i could apply lua coded effects on manually decoded audio chunks realtime; and it's been established before that audio generation/realtime synthesis is also possible (to a degree, though a small tracker is completely possible to implement), and both should work the same with the sounddatas that the recorder object returns.

To a degree as in pretty much on par with VST and other "normal" sound generators and processors.