search

Focusrite-Novation / r_cycle

NewInControlEnvironment
Apache License 2.0
82 stars 8 forks source link

BUTTON does not respect color_fg #2

Open worikgh opened 3 years ago

worikgh commented 3 years ago

Making a BUTTON and passing it a color_fg 88, say, has no effect on the button.

Passing color_bg 44, say, has the expected effect of changing the colour of the button on the device

The documentation says: [color_fg float( foreground color (ie selected pad) so I expect that when I select the button on the device (press it) I would see it change colour. It does not.

Using LAUNCHPAD X on a Raspberry PI 4

worikgh commented 3 years ago

On a perhaps related note: On trying out the examples I notice that the colour changes represented on the screen are not on the device (LP X).

For example the E_sequencing example when I press a butrton to trigger the sample it changes from green to red on my computer screen but not on the LP X.

zigmhount commented 3 years ago

Same here with LP X:

It doesn't seem to be a problem of LP_GUI interacting with LP X, but rather updating the LP X as per the buffers. Not sure whether it may be related to Heartbeat or not. @worikgh did you manage to get around or fix this?

worikgh commented 3 years ago

Sorry mate. I have stopped using this for now. I switched to a Python programme Griode.

I may be back, but not for a while

zigmhount commented 3 years ago

My bad, my previous post (deleted) was a bad solution to a wrongly identified problem - turns out that my first problem

Buttons that are lit up/colored via Pd messages or r_cycle GUI objects are turned off after pressing them (colored when pressed, then off).

was only due to conflicts between [LP_GUI]s and [FROM_LP_X], for which the 2nd argument "note/CC loopback (color)" lights up the button when pressed, thus turning it off afterwards, regardless of the widgets on LP_GUI. Removing the 2nd argument of all [FROM_LP_X] objects resolved the issue.

However I just found how to solve the issue about [pointer( and [GRID]: I believe that [pointer( may be have its specific meaning in Pd, causing error messages when sending [pointer 1( to a [route] such as bad arguments for message 'pointer' to object 'messresponder'.

I could not find any documentation confirming this, even though [pointer] definitely is an object described in the manual. I'm using Pd 0.51.1. Renaming [pointer $1( into [pointer_grid $1( and [route ... pointer ...] into [route ... pointer_grid ...] did the trick and solved the problem! Now the step sequencer shown in the tutorials actually light up the steps following the tempo :)

I guess that this is a real bug that should be fixed in r_cycle. I did not meet however the error that worikgh mentions though, [BUTTON] behaves as expected as far as I could see - as long as one is careful about conflicting LP_GUIs, GUI widgets and non-GUI objects (such as [FROM_LP_X]).

I hope this helps someone at some point!