raidho36 wrote:Probably works on iPhone though ...

Does anyone here happen to have the ability to test this theory? I don't have a Mac to build the iOS version of Love on.

It isn't supported yet. Ohhhhhh. :oops: Is mobile support for new features like this usually added much later, or is this likely to be functional by the time 0.11 is released? Edit: I didn't know what OpenAL was until I looked it up just now. If it doesn't support recording for Android, and therefo...

latest one is built properly Thank you, Mr. Jones! :awesome: I now have 0.11 up and running on my Android devices. Now, onto the next issue .... Has anyone else tried using RecordingDevice on Android yet? On both devices I tested on, getRecordingDevices() returns a single entry with an empty name (...

bobbyjones wrote:you can download minor now.

I appreciate the effort, but the .apk with "minor" in the name still appears to be 0.10.2 upon installation ....

zorg wrote:

Dr. Peeps wrote:Preferably non-sexual.

But... you're a bunny.

Ok fine. Sexual favours are back on the table.

I don't think he got around to working nightly builds of minor yet. Presumably they will be named differently? I wrongly assumed that this Android build was the same one as the Windows build on AppVeyor - the most recent. I guess if all else fails, I'll just have to get an Android build when 0.11 i...

I can build both the minor and default for Android nighyly. Just will have to set it up. Also I'll have to see if it even works without edits. That would be awesome. :cool: It turned out that last night's default Windows build (at https://ci.appveyor.com/project/AlexSzpakowski/love ) was 0.11, but ...

Excellent, slime. I just tested this idea by changing the example code from: data = inputs[ 1 ]:getData ( ) to: data:release() data = inputs[ 1 ]:getData ( ) 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....

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? This is ...

The absolute latest build from appveyor might be from either one of those branches depending on whether the most recent commit to the repository was in the 0.10.x branch (named 'default') or the 0.11 branch (named 'minor'). It all makes sense now, thanks slime. Can I assume then that if I want to n...