Looking for some suggestions (and an excuse to think through this problem).
I’m trying a new approach to my system, and I am hoping to make some space by ditching an Ornament and Crime and using crow as a quad sample and hold: 2 v/o voltages sampled by 4 triggers.
The basic scripting is easy! The rub is that, in order to have enough inputs, I am trying to share a TXi between two crows. There are no other devices on the chain. The first crow is polling the knob positions at a slower pace in order to control my percussion script. The other crow is polling the inputs to catch triggers.If the triggers are high, I am sampling the voltages on the second crow’s inputs and updating its outputs.
As is, it seems like I have to set the metro polling rate to hundredths of a second to avoid audible lag when testing for triggers. That also means I am flooding the i2c bus, and the percussion module has a tough time getting its messages. In an ideal world, I’d use the crow’s inputs to detect the triggers, but I need to sample 4 triggers, AND my TXi has 4 inputs that were not otherwise being used (I also don’t have room for a 3rd crow).
Even with the bonkers fast polling time, the S&H is still off sometimes.
S&H Source Code
state = {
[1] = false,
[2] = false,
[3] = false,
[4] = false
}
function init()
for i=1,4 do
output[i].slew = 0
output[i].scale({}, 12, 1.0)
end
metro[1].event = function(c)
for i=1,4 do ii.txi.get('in', i) end
end
metro[1].time = 0.003
metro[1]:start()
ii.txi.event = function( event, data )
--print(event.arg)
if event.name == 'in' then
chan = event.arg
-- if the trigger is high
if data > 1 then
if state[chan] == false then
state[chan] = true
sample(chan)
-- print(chan)
end
else
if state[chan] then
state[chan] = false
end
end
end
end
end
function sample(channel)
if channel < 3 then
output[channel].volts = input[1].volts
-- print(output[channel].volts)
else
output[channel].volts = input[2].volts
end
end
I could potentially have one crow do all of the polling and then instruct the second crow to do it’s sampling, but that would still require getting messages through on a busy i2c bus.
I realize this isn’t the ideal way to do this, but I’m trying to use the resources I have available.
If anyone has any clever notions about how I could accomplish this more reliably, I’d welcome any insight!
PS - In case this is helpful to anyone else: After making my own i2c cables, the issues I was having with my TXi appear to have completely gone away? I’d tried 3 different cables, and all of them were having periodic dropouts at random times after startup (which required a system reboot). I was never able to catch the moment it happened with debugging enabled, so I still am not sure what what happening. But if you are having mystery i2c dropout issues, keep trying new cables!
Edit: Continuing to think on this, I’m wondering if altering the TXi’s firmware to make it behave like a pseudo leader is the best solution? The crow could register itself as a listener, and the TXi could send messages based on changes to quantized values? Or something like that.
I’ve already got another daunting firmware project to tackle, so it’s definitely not my preferred solution. However, it would reduce the traffic on the i2c line by an order of magnitude, as the TXi is better equipped to notify the crows of changes, in my particular case, rather than the other way around.
