• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Some requests/suggestions
#16
How much of a delay are you seeing what type of device is it on? I'm not seeing any delay at all on my Samsung Tab S4. I have to generate the audio dynamically before it can be looped, so I'm very curious what is introducing the delay you are seeing on the device. At the moment, I'm utilizing the AudioTrack code in Google's audio library (https://developer.android.com/reference/...AudioTrack) which usually works with low latency. However, this is different than the approach used in the Windows version where I dynamically generate an audio file that represents one full loop of the metronome, and I just play that file on repeat. If you want to work with me, I can try creating a build where I dynamically generate the file like on Windows and we can see if this works better than the current approach.

Mike
Reply
#17
Hi Mike,

Thanks.

I haven't tried the windows version so far, so can't tell whether or not that makes a difference.

I'll try and make a video recording of the delay I'm seeing. I've run into it on my tab s3 and also on my (go to testing unit) samsung a52.

Until then, you might try playing some random BPM-steady track like this one https://youtu.be/85ZptB9kgaM and set the MSP metronome to the same BPM (95 in this case).

Then try and match up the MSP metronome with the playback beat. I notice I need to initiate it a fraction earlier than the actual beat. I've grown capable of doing that over time, but it's not ideal Smile
Reply
#18
I've had a chance to explore this a little more - the approach I'm using on Android just has too much initial latency to be used accurately. So I'm going to need to switch to either generating the metronome loop in memory and then playing that, or use the same approach as the Windows version which generates an audio file temporarily that has the entire metronome loop and then I just play that in a loop like I would with any other audio file. I'm probably going to go with the file-based approach because the amount of data needed to represent a very slow bpm over the the entire metronome loop is actually quite a bit, so it's more efficient to generate a temporary file than to consume a lot of memory on the device for this.

Thanks,
Mike
Reply
#19
Awesome, sounds like a good solution. Thanks!
Reply
#20
I released changes with version 3.4.9 that should help with the issues you were encountering with the metronome. With the latest changes, I can now accurately start the metronome to match an existing beat, and I also improved the accuracy over time. In the previous version, even if you did manage to start the metronome at the right time, over time it would gradually get off beat. The new approach works much better in this regard. Please test it when you get a chance and let me know if it works better for you as well.

Mike
Reply
#21
Thanks Mike!

Metronome playback now starts instantly, perfect!

I noticed some inaccuracy over time when compared to Google's 'built-in' metronome.
But when I run it along a metronome app on my phone, they stay in sync. 

I'm guessing Google's metronome is at fault here.

Thanks for the quick fix!
Reply
#22
I tested at 120 bpm with a very accurate metronome app, and MobileSheets stayed in sync for 5 minutes without any variation, so I think it should be just fine. When using some bpms that don't divide evenly, each metronome can handle the fractional values differently, so you can get a small amount of variation over time.

Mike
Reply




Users browsing this thread:
1 Guest(s)


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2024 MyBB Group.