poll: vu in/out for ui

[tehn]

we have mono polls for in/out, but wondering if those should be reserved for user scripts and a system-level poll (array returned) would be better for vu displays. the data could be publicly available to user scripts as well of course.

[catfact]

yeah in general i am not sure how to structure multichannel polls. i agree we should have them.

blobs are easy, but constructing and decoding blobs for everything is a little dumb. matron events already support blobs and i will certainly use these for e.g. waveform displays

float arrays are actually kind of weird in liblo. i will poke at them a little more.

of course arbitrary argument lists are fine. but they need more scaffolding to glue with the event queue and with lua. i really don't love the brittle, dynamically-allocated "registry" of engine commands with arbitrary arg lists. but of course we can just recycle that approach, it's ok.

maybe for a pack of VU data, blobs are ok. like each channel can acceptably fit in 8b. thoughts?

[tehn]

for vu data 8b would certainly be enough.

On Wed, Jan 31, 2018 at 9:35 PM, ezra buchla notifications@github.com wrote:

yeah in general i am not sure how to structure multichannel polls.

blobs are easy, but constructing and decoding blobs for everything is a little dumb. matron events already support blobs and i will certainly use these for e.g. waveform displays

float arrays are actually kind of weird in liblo. i will poke at them a little more.

of course arbitrary argument lists are fine. but they need more scaffolding to glue with the event queue and with lua.

maybe for a pack of VU data, blobs are ok. like each channel can acceptably fit in 8b. thoughts?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/catfact/norns/issues/70#issuecomment-362139560, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPEcORfqWl2JVlKB1Ph4AbFSpBmeFemks5tQSLqgaJpZM4RxXXW .

[catfact]

ok, how low can we actually go with resolution for vus?

i'm planning that the data returned from SC will already be log-scaled.

thinking somehting like 64 steps, top value is 0db, each step is 1db down to -60, below that its linear to 0.

is that enough?

( this is in order to implement reverse audio taper with maximal efficiency - like maybe not having to call log)

[tehn]

that seems totally enough!

On Wed, Feb 7, 2018 at 2:46 PM, ezra buchla notifications@github.com wrote:

ok, how low can we actually go with resolution for dbs?

i'm planning that the data returned from SC will already be log-scaled.

thinking somehting like 64 steps, top value is 0db, each step is 1db down to -60, below that its linear to 0.

is that enough?

( this is in order to implement reverse audio taper with maximal efficiency - like maybe not having to call log)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/catfact/norns/issues/70#issuecomment-363888127, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPEcCq_btaq4eLIyvmHyMFv-d_RmXiPks5tSf2XgaJpZM4RxXXW .

[catfact]

@tehn i'm assuming the idea is to handle VU levels in lua, right?

[tehn]

yep. just need vu data for drawing on the screen.

[catfact]

can we close this?