elgiano
commented
3 years ago I'm now working on removing BelaScopeUGen and leaving only BelaScopeOut. The idea is to give a memory block (float, which size should be maxScopeChannels blockSize) to SC_BelaDriver, and letting BelaScopeOut write directly to it. Then, after rendering, if the server was booted with belaMaxScopeChannels > 0, SC_BelaDriver logs that buffer to Scope.log frame by frame. This will mean a lot less complications in sclang, no need to reserve busses, no need to keep track of unique instances of synths. However, I'm getting funny results that I don't really understand. I'll link my current code and a screenshot, if you have any idea about what's going on, that would be immensely appreciated.
https://github.com/elgiano/supercollider/commit/79756bc003e3c449a40179ab9f468df88a0960e4
P.S.: sorry if that code will be a bit messy (i.e. not the best organization), I basically wanted to make a proof of concept
This was meant to be a straight horizontal line DC.ar(0.5) ...
Purpose and Motivation
While trying to fix problems with remote servers and Oscilloscope, the implementation was becoming too complex IMO. I rethought it and removed Bus reservation from the mechanism. I kept the interface the same, but changed the implementation. Now BelaScopeUGen allocates a region of memory (called
frameData), where another UGen can write. BelaScopeOut writes data to that region, and BelaScopeUGen is responsible for logging it to Scope, and clearing it, once per block.This fixes problems with multiple or restarting clients, which ranged from unnecessary multiple BelaScopeUGen instances to Bus reservation mismatches.
As an addition, BelaScopeOut can survive when BelaScopeUGen stops working. When a new BelaScopeUGen will be active, it will continue to visualize data coming from survived BelaScopeOuts.
Types of changes
Checklist