12-07-2017, 05:54 AM | #121 |
Banned
Join Date: Feb 2014
Location: Moscow, Russia
Posts: 554
|
Tried to solve acceleration issue with the following workaround:
1. Get value from encoder (1+ clockwise, 65+ counter clockwise, depending on rotation speed). 2. Check the direction and store it, so CCW will give -1 argument to /r/scroll and CW will give positive argument. 3. Divide 64 out of CCW value, so that both directions would give 1+ values. 4. Check if the value is higher that 12, cause, otherwise, the cursor would jump across the project like crazy. 5. Run loop for osc action /r/scroll with positive or negative argument, based on direction of rotation. Do it as many times as the CC "times", but not more than 12 times. 6. Done. The problem is that it's not working. According to Reaper's log, osc command is sent only once per encoder's click. Here's the code (pic and text): https://i.imgur.com/fG7f319.png http://pastebin.ru/rwGkCCbD oscii-bot log shows that printing in loop works both when "times" argument is set as an integer or taken from CC value: https://i.imgur.com/2JsEAqV.png Is it some kind of oscsend protection that doesn't allow multiple similar osc messages to be generated? Last edited by fundorin; 12-07-2017 at 06:05 AM. |
12-07-2017, 05:56 AM | #122 | |
Banned
Join Date: Feb 2014
Location: Moscow, Russia
Posts: 554
|
Quote:
Last edited by fundorin; 12-07-2017 at 06:14 AM. |
|
12-08-2017, 02:04 AM | #123 |
Banned
Join Date: Feb 2014
Location: Moscow, Russia
Posts: 554
|
Solved
|
12-08-2017, 06:30 AM | #124 |
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,789
|
What is the purpose of posting the code and the video ?
Do you want to donate it or do you suggest there are errors ? -Michael |
12-08-2017, 09:26 AM | #125 |
Banned
Join Date: Feb 2014
Location: Moscow, Russia
Posts: 554
|
What?
I had an issue (see my previous messages), while trying to accelerate jog movement of the cursor via encoder on the console in my script. I've failed in achieving the goal yesterday, as well as Banned with his MIDIMIX script, but then I found a way to make cursor faster, depending on the encoder's rotation speed. The video shows the result and the code shows how it was done. I thought that it would be nice to share, in case if someone else would want to have similar functionality in their code. |
12-08-2017, 09:56 AM | #126 |
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,789
|
Great !
Thanks ! Please pardon my ignorance. -Michael |
12-13-2017, 07:54 AM | #127 | |
Banned
Join Date: Feb 2014
Location: Moscow, Russia
Posts: 554
|
Quote:
|
|
12-18-2017, 07:06 PM | #128 |
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,746
|
Hmm, /track/1/monitor works, but it only acts as a 3-way cycle (you can't force a particular setting). Fixing that!
Last edited by Justin; 12-18-2017 at 07:45 PM. |
12-19-2017, 05:21 AM | #129 | |
Banned
Join Date: Feb 2014
Location: Moscow, Russia
Posts: 554
|
Quote:
For me, "b/track/1/monitor" with argument 1 enables monitoring. Then, arg 0 switches it to auto and the next command with arg 0 turns it off. Tried adding "t/track/1/monitor" to the config. Doesn't work. Quite the contrary, I would like to toggle 3-way cycle with a single button. Just like it works in your case. And, maybe, two-way cycle, with only on/off, excluding "auto" mode. P.S. While we are on the subject, could you, please, fix this OSC learn assignment bug? https://forum.cockos.com/showthread.php?t=200551 P.P.S. Also, please, add "Mixer view scroll horizontally to the track bank, when selected from the device", when DEVICE_TRACK_BANK_FOLLOWS DEVICE. For now, MCP only scrolls when DEVICE_TRACK_BANK_FOLLOWS MIXER, but with this option, banks move from 1-8, 9-16 to other values and that isn't what I want. Thanks in advance. Last edited by fundorin; 12-19-2017 at 06:26 AM. |
|
12-19-2017, 07:57 AM | #130 |
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,789
|
To me cycling (and toggling) settings seems rather inappropriate for a protocol, as dedicated values can easily used in a cyclic way, but auto-cycling values can hardly be used in a deterministic way.
If the user wished to have cyclic "single button" handling, it should be implemented at the user interface or intermediate site. -Michael |
12-19-2017, 10:45 AM | #131 |
Banned
Join Date: Feb 2014
Location: Moscow, Russia
Posts: 554
|
Cycle and direct selection should exist along each other. Otherwise, some of the existing setups might break.
The more options, the better. Not every osc device is able to compute some extensive script logic. Apart from scripts and software, many hardware devices exist, that can only send a single command with an argument upon the button press. |
12-21-2017, 02:57 PM | #132 |
Banned
Join Date: Feb 2014
Location: Moscow, Russia
Posts: 554
|
LCD text request
I'm requesting current info from the LCD, so in response, the surface will text from the LCD in sysex format. The thing is that partial data request wasn't implemented by Novation devs, so the surface always sends all text from both LCDs at once. it looks like this:
The thing is that the data is too big to fit in one message, so it's split in two: Using the example that Justin's or John's example, I'm trying to print the incoming message to the console with the following code. The data is requested with this code and it works, as can be seen from above: Code:
lcdRequest = "\xF0\x00\x20\x29\x03\x05\x10\x05\x00\x00\x66\x04\x00\x00\x20\xF7"; msg1 == chan && msg2 == slAu[2] && msg3 == 65 ? ( midisend_str(midi_out, lcdRequest); // data request printf("LCD: %s\n",hex2str(oscstr)); // should print the same as midi-ox does ); I feel like this might happen for some other reason, apart from the data is split in two sysex messages, and I wonder, why is this happening and how to store the whole data, so that I could resend it back to the surface later? |
12-22-2017, 01:29 AM | #133 |
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,789
|
I don't seem to understand your code.
Do you really do midisend_str(midi_out, lcdRequest); // data request and in the next instruction expect the answer of the request to be in oscstr by printf("LCD: %s\n",hex2str(oscstr)); This can't work, as the program needs to wait for the answer to appear in a "@midimsg" event (and - AFAIK - check the msg byte if they are as expected) before OSC can be assumed to contain the sysex message. (I suppose the splitting in two blocks is just a fake introduced by MidiOX.) -Michael |
12-22-2017, 02:49 AM | #134 |
Banned
Join Date: Feb 2014
Location: Moscow, Russia
Posts: 554
|
Sysex incoming messages appear in oscstr.
It was Justin's decision to do so. I'm using the same construction to compare incoming sysex message from the surface at startup: As you can see from midi-ox screenshot, requesting sysex from the script is working. as you can see from this code, displaying incoming sysex message in log also works: Last edited by fundorin; 12-22-2017 at 02:55 AM. |
12-22-2017, 04:28 AM | #135 |
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,789
|
Yep, but of course only after they in fact did arrive.
The receive-variables (msgX and oscstr) only feature defined values in the appropriate @... event handlers: msgX in @midimsg, and oscstr in @oscmsg. Additionally oscstr in @midimsg in case the msg1 indicates that a SysEx message has been received. In any case, OSCII-Bot is an event-driven software system and does not wait on anything, anytime. Hence after sending out a midi message which needs to travel to the recipient and the answer needs to travel back, OSCII-Bot has long been gone to sleep before the answer is in sight. So a new @midimsg event will be fired not before the answer completely has been received and stored to msgX and (in case of SysEx) to oscstr. -Michael |
12-22-2017, 06:32 AM | #136 |
Banned
Join Date: Feb 2014
Location: Moscow, Russia
Posts: 554
|
I don't understand what you're trying to tell me. Those are basic things that you've written.
If you'd check my quoted code, you'd see that I'm requesting LCD data with a button on the surface (CC message) in @midimsg section. Again, 1470 - 1474 - already working code, that displays oscstr in the log. 1477-1480 is my lcd request, that doesn't display anything. |
12-22-2017, 01:05 PM | #137 |
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,789
|
Sorry.
Seemingly English derived from Russian is than much different from English derived from German, that we are not able to communicate (I did have this impression already before). So maybe a native English speake might chime in and translate. Anyway I'll give it another try: >> midisend_str(midi_out, lcdRequest); // data request >> printf("LCD: %s\n",hex2str(oscstr)); // should print the same as midi-ox does This will not work. After sending OSCII-Bot will not wait for a reply, and hence oscstr is evaluate before any data is attached to it. You should go (untested): in @midimsg, @timer or @oscmsg : ... midisend_str(midi_out, lcdRequest); // data request ... in @midimsg: ... (msg1 & $xF0) == $xF0 ? ( // this is a SysEx test_if_an_LCD_message_is_expected ? ( printf("LCD: %s\n",hex2str(oscstr)); // should print the same as midi-ox does ); ... ); ... -Michael Last edited by mschnell; 12-22-2017 at 01:10 PM. |
12-22-2017, 05:09 PM | #138 |
Banned
Join Date: Feb 2014
Location: Moscow, Russia
Posts: 554
|
Do you mean I should just separate send and receive functions?
I might try. But, I would need to partially match compare all the incoming sysex messages to store only LCD data related ones. Seems logical. |
12-22-2017, 11:17 PM | #139 | |
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,789
|
Quote:
Other Systems might provide "blocking Read" functions that internally wait (potentially forever) for something to happen (e.g a message comes in from some sender). This is problematic, as while waiting, the system can't react on other stuff happening (e.g. a timer is scheduled, ...). So it is just fine that OSCII-Bot does not feature any blocking functions (but "sleep()", that should be use with great care), and works just "event driven". -Michael |
|
Thread Tools | |
Display Modes | |
|
|