Re: [sc-users] Building UGens with shared resources so that constructors/deconstructors work with JITLib

If you only need either a single or a fixed number of connections for the lifetime of your plugin, setting these up during plugin initialization rather than UGen construction might be the right approach.

If each UGen can potentially have a different connection, you'll have to pool them and reference count, something like what Christof suggested - keeping in mind that JITlib will Crossfade running synths, so supporting two ugen instances pointed to the same sensor connection is absolutely required.

If resource management is too complex, and the overall number of connections you'll have is finite (e.g. someone can attach 20 sensors, but not 2000), you might consider creating them lazily, sharing them between ugens, and keeping them alive for the duration of the plugin - this could even improve performance if there's overhead in creating / destroying connections.

- S

On Mon, Nov 25, 2019, 3:30 PM <christof.ressi@xxxxxx> wrote:

Each hardware I2C bus might be represented by a global object with a reference count. When a UGen connects to a certain I2C bus, its refcount is incremented; when a UGen disconnects from a I2C bus, its refcount is decremented. If the refcount goes from 0 to 1, the "actual" connection to the I2C bus is made; if the refcount goes from 1 to 0, the "actual" connection can be closed; otherwise you don't need to do anything.

This is how the OS manages many ressources under the hood.
Christof
Gesendet: Montag, 25. November 2019 um 14:35 Uhr
Von: info@xxxxxxxxxxxxxxxx
An: sc-users <sc-users@xxxxxxxxxxxxxxxx>
Betreff: [sc-users] Building UGens with shared resources so that constructors/deconstructors work with JITLib
Dear all,

This is a rather technical question, so please let me know if I should better post it in sc-dev.

Right now I'm developing a kr UGen that reads data in from a specific sensor over an I2C bus. When this UGen is instantiated, there is code in its constructor method that creates an I2C object which establishes a connection to the I2C bus and configures everything properly. And inside the deconstructor method there is code that cleans up the I2C bus and then deletes the I2C object.

The UGen works fine when synths are manually instantiated and freed, but encounters some problems when using it inside an Ndef (nodeproxy).

The problem as I can see it (from print statements) is that when I update the UGen graph of a running Ndef, the order of allocation/deallocation goes something like this:

1. UGens of the new graph are instantiated (I get a "hello world" print statement from my UGen's constructor) - however there is already an existing I2C connection being managed by the already existing UGen instance (BAD!)

2. UGens of the old graph are de-allocated (I get a "goodbye world" statement from my UGen's deconstructor) - the "clean up I2C bus" code is called by the old UGen while the new one has an active connection to the I2C bus that it is managing (ALSO BAD!)

Does anyone on the list have any suggestions for how to deal with this behavior? I would very much like to be able to use JitLIB in developing programs with this UGen... there must be some clever way to specify the order of allocation/deallocation? Or...?

any thoughts are very welcome!

best

Jon
--
JReus

jonathanreus.com
sensorycartographies.info
anatomiesofintelligence.github.io

Recent:
Interview with PERFORM-TECH, by Fionn Han
Interview with Asko-Schönberg Ensemble
Interview with Leuphana University, Teaching Prize for Cross-Disciplinary Education Across Arts, Science and Humanities
_______________________________________________ sc-users mailing list info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx archive: https://listarc.bham.ac.uk/marchives/sc-users/ search: https://listarc.bham.ac.uk/lists/sc-users/search/