ok, I did a bit of digging π
it appears the issue is with the digitalOut , when using it 'write on change' mode.
so we can get it to work using continuous mode.
here are two working examples
the first shows all 3 states, so off/orange and red.
note: because off is achieved by reading the pin, we use DigitalIO.
(it works at ar() but, I used kr as seemed most useful generally)
so here we see off, off,red, orange
DigitalOut.ar(digitalPin:7, output:LFPulse.ar( freq:(44100/32), width: 0.75), writeMode:1);
DigitalIO.kr(digitalPin:2, pinMode:0,output:0);
DigitalIO.kr(digitalPin:4, pinMode:0,output:1);
DigitalIO.kr(digitalPin:8, pinMode:1,output:0);
DigitalIO.kr(digitalPin:9, pinMode:1,output:1);
here I show setting to red , and modulating the pulse width to change brightness.
var pwm = SinOsc.ar(freq:0.1,mul:0.5,add:0.5);
DigitalOut.ar(digitalPin:7, output:LFPulse.ar( freq:(44100/32), width: pwm), writeMode:1);
// DigitalOut.ar(digitalPin:2, output:0,writeMode:1); // does not work!
// DigitalOut.ar(digitalPin:2, output:DC.ar(0),writeMode:0); // does not work!
DigitalOut.ar(digitalPin:2, output:DC.ar(0),writeMode:1);
here you can note a few things, first how write mode = 0 does not work (and is the default!) , also it appears the initialisation input is not working (i.e. if we set output:0)
so thats the 'use case that work'
a bit of background, as to why something work and not, just to help not get caught out.
basically all the parameters can either be 'static' (I guess ir() ?), kr() , or ar() and the code is slightly different, also then we have the write mode (0) 'on change', the default - or continuous (=1)
I did have a quick look at the code, and the 'on change' code is pretty simple, it basically just stores the last value, and sends if its changed, so im not sure if the bug is there, or just the way the pins are used.
there are also variations where digitalWrite is used vs digitalWriteOnce, but Ive not looked into this.
I suspect none of this is a real issues, seeing the above codes seems to cover most use-cases, but I suspect if we start doing other variations where we alter things at varying kr() ar() we might keep tripping over these issues.
(Im not sure to say bugs, as im not 100% sure if its software or hardware)
so what appeared not to work (or as expected)
- digitalOut.ar() - writeMode:0
- digitalOut.ar() with static output , so i guess ir()/once, or kr() (e.g. DC.kr(0) )
- digitalOut.kr(), seem to never work
p.s. the best way to test is to to try to set the LED to red (so 0) , as on the 'fail cases' the LED goes to orange (1), despite being set to red(0)