Position notification improvements about mwengine HOT 8 CLOSED

Ah, well spotted! Hadn't seen that! I'm currently on holiday without a computer until Dec 8th, but we can discuss in the meantime. Can you explain the use case of point #2 as I'm confused about that one.

from mwengine.

About 2):
I need to sync music beats with UI events (animation) and user feedback (touches).
I've no problem on devices with low latency.
But on my Xperia S latency is too high, about 250ms.
I've divided bar with 48 subdivisions to put 16th and triplets.
WIth 4/4 and tempo 90bpm time gap between subdivisions is 60_1000/90_4/48 = 55ms. It less than latency and less than buffer size. So position updates happens more than one time for buffer write, with no delay.
I need information about sample count before position update to sync my app with music perfectly. I can add calculated delays for my events, if I need to sync it perfectly.

from mwengine.

Makes a lot of sense! So in your proposed fix in your fork you'll take care of the actual calculation in Java? Works for me, as the very purpose of this update is to sync UI. I'll be sure to take the changes from your fork, update the Wiki and example accordingly and givr you credit for your contributions when I get back. :)

from mwengine.

So in your proposed fix in your fork you'll take care of the actual calculation in Java?
Yes, API just provides information.

Calling observer at exact time would be much better, but seems to be much harder task.

On 30 нояб. 2015 г., at 15:44, Igor Zinken [email protected] wrote:

Makes a lot of sense! So in your proposed fix in your fork you'll take care of the actual calculation in Java? Works for me, as the very purpose of this update is to sync UI. I'll be sure to take the changes from your fork, update the Wiki and example accordingly and givr you credit for your contributions when I get back. :)

—
Reply to this email directly or view it on GitHub #17 (comment).

from mwengine.

@hypeastrum all back and ready to get to work :)

I've been looking at your fork and like a lot of your improvements! (the conditionals on the recording buffers in particular!)

I have a question regarding your changes to the handleSequencerPositionUpdate() method. Instead of passing the timestamp (which was indeed unused), you now pass to the sample position within a range of 0 to AudioEngineProps::BUFFER_SIZE. My question is what is the result of the:

( stepPosition << 16 ) | pendingSamplingCount )

...bitwise calculation, wouldn't the value of bufferPosition be enough to pass via JNI ? You could then determine the current step position using Math.floor( bufferPosition / MWEngine.BYTES_PER_TICK ) and the "progress" into the next step by calculating the amount of samples that are pending, e.g. : ( nextBufferPosition * MWEngine.BYTES_PER_TICK ) - bufferPosition (BYTES_PER_TICK is really the amount of samples for each step within your sequence, and is up for renaming to avoid confusion!)

perhaps I'm not sure how you're treating the value in your application in Java :)

from mwengine.

Hi! I've spend nice holidays too =) and ready to work again

The way you suggested should work too. API will be more accurate.
What about making some low level engine params (incl. bufferPosition) accessible through special java class?

On 14 дек. 2015 г., at 23:49, Igor Zinken [email protected] wrote:

@hypeastrum https://github.com/hypeastrum all back and ready to get to work :)

I've been looking at your fork and like a lot of your improvements! (the conditionals on the recording buffers in particular!)

I have a question regarding your changes to the handleSequencerPositionUpdate() method. Instead of passing the timestamp (which was indeed unused), you now pass to the sample position within a range of 0 - BUFFER_SIZE of the engine. My question is what is the result of the:

( stepPosition << 16 ) | pendingSamplingCount )
...bitwise calculation, wouldn't the value of bufferPosition be enough to pass via JNI ? You could then determine the current step position using Math.floor( bufferPosition / MWEngine.BYTES_PER_TICK ) and the "progress" into the next step by calculating the amount of samples that are pending, e.g. : ( nextBufferPosition * MWEngine.BYTES_PER_TICK ) - bufferPosition

perhaps I'm not sure how you're treating the value in your application in Java :)

—
Reply to this email directly or view it on GitHub #17 (comment).

from mwengine.

@hypeastrum : I finally got around to make the changes. I have taken some of your optimizations of the engine, as well as worked on your request regarding the position notifications.

Could you review the branch "position-notification" (see pull request #18 for details), basically the notification now broadcasts the current buffer position to Java, and you can use new getters inside SequencerController to retrieve the buffer position, samples per bar/beat, etc. type values. Are these sufficient or would you need more engine properties exposed to Java ?

from mwengine.

Changes verified, updated and merged to master.

from mwengine.