anokta / barelylooper Goto Github PK

probably something like an input module (inherited from baseinputmodule) + graphicsraycaster in addition to a custom input manager to handle the rest of the game items would work the best.

Currently uses buffer length samples in each side of loop with exponential decay. Could be worth investigating if there's a better way of handling the start/stop glitches..

e.g. Reticle shader could be modified to show a circular loop progress bar.

After the recent fixes (78f75f3), they are seemingly outdated.

Should be able to playback in sync with the loops before and after the loop playback starts.

Would be cool to have - automated - moving loops around head!

to allow adjusting global settings such as overall volume, vr mode/recenter camera, changing tempo/number of beats etc.

glitchy behaviour when the record is longer than loop length

With a solution for #17, some simple audio effects (such as low pass, distortion etc) could be introduced with scalable zones (similar to reverb zones) that can be placed in the 3d environment to affect the loops inside these regions.

Drag & drop, change distance, record paths & more!

Would potentially allow a 'marriage' with certain barelyMusician functionality!

ideally as minimalistic as possible - maybe as simple as short/long noise samples?

Most feasible option seems to be:
Store each looper with its current transform, audio data, starttime etc. and recreate the scene on load.

When StopRecording is called, the record cursor is behind the current time, which ends up having a wrong record clip length. Could be possibly fixed by the following steps:

1. (optional) Always keep recording and save the very first dsptime when start recording to get the latency.
2. When StartRecording, compare the (current - initial dsptime) % record length with the cursor to find out the current latency.
3. When StopRecording, again compare the dsptime with the cursor to find out how long the record is behind, then:
   a. Immediately return the current data and fade in the first samples
   b. Start a coroutine to wait for Microphone.GetPosition(null) >= targetdsptimesamples + 2 * crossfadetimesamples, then send back the real data.
   c. Update the looper data by crossfading both ends for seamless loop.

The 3rd step may require the streaming audioclip or onaudiofilterread methods to avoid glitches on data update.

While this overall sounds rather complex, could solve the syncing issues for good!! <3

Can loopers be light sources?

needs server-side tools too?

Esp. a must to have, more sophisticated - e.g. frequency based - dynamic visualizations!

Also, it's possibly needed to do a semi-regular check to ensure microphone is still alive, otherwise restart. Will know more after some further tests..

needs research..

For starters, could be fun to have by just changing pitch to make loops faster/slower accordingly.