• Trill

  • Trill UGens acting up?

Hello, I was hoping to use Trill Craft with SuperCollider on Bela, so I followed the instructions here: https://github.com/giuliomoro/Trill_SC

It went smooth seemingly, but when I run the example file SC_TrillRaw_Example, I get the following error.

Underneath you can see I checked that the supercollider classes were actually installed under TrillUGens, inside the Extensions folder. Moreover, Trill Craft is currently connected and if I run
i2cdetect -y -r 1
I get

and although the formatting is super weird, I think it suggests that the I2C sensor is read on the address 0x30.
This is a copy of the example code I'm tryna run:
`
s = Server.default;

s.options.numAnalogInChannels = 8; // can be 2, 4 or 8
s.options.numAnalogOutChannels = 8; // can be 2, 4 or 8
s.options.numDigitalChannels = 16;
s.options.maxLogins = 8;

s.options.pgaGainLeft = 5; // sets the pregain for the left audio input (dB)
s.options.pgaGainRight = 5; // sets the pregain for the right audio input (dB)
s.options.headphoneLevel = -1; // sets the headphone level (-dB)
s.options.speakerMuted = 1; // set true to mute the speaker amp and draw a little less power
s.options.dacLevel = 0; // sets the gain of the analog dac to (dB)
s.options.adcLevel = 0; // sets the gain of the analog adc to (dB)

s.options.blockSize = 16;
s.options.numInputBusChannels = 10;
s.options.numOutputBusChannels = 2;

s.waitForBoot {
tr = {|t_updateTrill = 1.0|
var numTouchPads = 26;
var i2c_bus = 1; // I2C bus to use on BeagleBone, usually you want this to be 1
//var i2c_address = 0x18; // I2C address of Trill sensor
var i2c_address = 0x30;
var noiseThresh = 0.01; // float: 0-0.0625, with 0.0625 being the highest noise thresh
var prescalerOpt = 1; // sensitivity option, int: 1-8 (1=highest sensitivity, play with this for complex Trill Craft setups)
var rawvals;
var sig, ping;

rawvals = TrillRaw.kr(i2c_bus, i2c_address, noiseThresh, prescalerOpt, t_updateTrill);
SendReply.kr(Impulse.kr(2), "/trill", rawvals);
sig = SinOsc.ar((1..numTouchPads) * 50, mul: Lag.kr(rawvals, 0.1)) * 0.6;
sig = Splay.ar(sig);
sig = CombL.ar(sig.sum, 0.2, 0.2, 3.0, mul: 0.4) + sig;
ping = EnvGen.ar(Env.perc, t_updateTrill) * SinOsc.ar(440);
sig + ping;
}.play;

OSCdef(\trill, {|msg| msg[3..].postln }, "/trill");

{ // Illustrates updating the baseline should the configuration change while the sketch is running
	loop {
		55.wait;
		"Reset Trill baseline in 10s...".postln;
		5.wait;
		"Baseline Reset".postln;
		~tr.set(\t_updateTrill, 1);
	};
}.fork;

};
`

Any idea what the deal is? 🙁

The cue was a few lines above when supercollider starts and prints:

Compiling class library...
	Found 726 primitives.
	Compiling directory '/usr/share/SuperCollider/SCClassLibrary'
	Compiling directory '/usr/share/SuperCollider/Extensions'
	Compiling directory '/root/.local/share/SuperCollider/Extensions'

There you see that /usr/local/share/SuperCollider/Extensions is not in use as modern installs of Supercollider on Bela are in /usr/share/SuperCollider (not /usr/local). Another hint would have come from the fact that you probably had to manually create /usr/local/share/SuperCollider/Extensions before you managed to create the symlink in it using the ln command suggested by the README.

Even better, the best place to place these is probably not in the /usr folder but in ~/.local/share/SuperCollider/Extensions. I updated the README accordingly.

Thank you for spotting this!! this was exactly the problem. Now Trill Craft is red and values are printed correctly.

Just out of curiosity, are these warnings something I should be concerned about?

They appear every time I run SC_TrillRaw_Example

(heading over to try your other method 🙂 )

I think the warning about not being a linear 1-D sensor should be ignored.

The mode switches and dropouts are expected, as long as they only happen when the patch starts and don't keep happening while it's running.

    giuliomoro
    Yea that's the case 🙂 could I ask you why dropouts and mode switches are expected at startup? Is it related to the crazy CPU usage (up to 47% with nothing but the example sketch running!), and is there something I can do to optimize this?

        robinm dropouts and mode switches are expected at startup?

        Because the object is created and the sensor is initialised in the audio thread.

        robinm Is it related to the crazy CPU usage

        No, that's a one-off initialisation cost.

        robinm up to 47% with nothing but the example sketch running!), and is there something I can do to optimize this?

        The trill ugen itself doesn't show anything obviously horribly bad. I think that cpu usage is mostly down to the sound generation used in the example.