Microphone Support for LÖVE!
- zorg
- Party member
- Posts: 3465
- Joined: Thu Dec 13, 2012 2:55 pm
- Location: Absurdistan, Hungary
- Contact:
Re: Microphone Support for 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.
Me and my stuff
True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
![Awww :3](./images/smilies/ms-three.png)
Re: Microphone Support for LÖVE!
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.Dr. Peeps wrote: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?LÖVE 0.11 wrote:getData removes currently recorded samples from input and puts them into new SoundData
- slime
- Solid Snayke
- Posts: 3156
- Joined: Mon Aug 23, 2010 6:45 am
- Location: Nova Scotia, Canada
- Contact:
Re: Microphone Support for LÖVE!
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.
This will help to keep consistent performance in the case where you're creating and throwing away objects.
- zorg
- Party member
- Posts: 3465
- Joined: Thu Dec 13, 2012 2:55 pm
- Location: Absurdistan, Hungary
- Contact:
Re: Microphone Support for LÖVE!
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)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.
Me and my stuff
True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
![Awww :3](./images/smilies/ms-three.png)
- slime
- Solid Snayke
- Posts: 3156
- Joined: Mon Aug 23, 2010 6:45 am
- Location: Nova Scotia, Canada
- Contact:
Re: Microphone Support for LÖVE!
Before. You won't have access to it after setting the variable to nilzorg wrote:When should i call the object:release, if i should at all? before or after nilling?
![Smile :)](./images/smilies/ms-smile.png)
Sure, since it makes it more explicit in your code that the object is no longer usable.zorg wrote:Should i even nil the variable?
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.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)
Re: Microphone Support for LÖVE!
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.
Code: Select all
data = inputs[ 1 ]:getData ( )
Code: Select all
data:release()
data = inputs[ 1 ]:getData ( )
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.
Re: Microphone Support for LÖVE!
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.
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.
- buckle2000
- Prole
- Posts: 6
- Joined: Wed Oct 14, 2015 10:02 am
Re: Microphone Support for LÖVE!
Realtime intercom, if I'd say.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?
- zorg
- Party member
- Posts: 3465
- Joined: Thu Dec 13, 2012 2:55 pm
- Location: Absurdistan, Hungary
- Contact:
Re: Microphone Support for LÖVE!
Actually, to some degree, you can process voice commands in realtime.buckle2000 wrote:Realtime intercom, if I'd say.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?
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.
Me and my stuff
True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
![Awww :3](./images/smilies/ms-three.png)
Re: Microphone Support for LÖVE!
To a degree as in pretty much on par with VST and other "normal" sound generators and processors.
Who is online
Users browsing this forum: Google [Bot] and 3 guests