Jump to content

richmaes

Members
  • Content Count

    12
  • Joined

  • Last visited

Community Reputation

0 Neutral

About richmaes

  • Rank
    Just Startin'

Profile Information

  • Registered Products
    11
  1. richmaes

    Helix Bug Reports

    I went back to the Helix in question and found that it was still running v.2.20, so my mistake. I updated to v.2.21 and re-checked the behavior. It seems solid enough now for for what I was expecting. So mark that bug "Pilot error"
  2. richmaes

    Helix Bug Reports

    In the Helix V2.21.0 release, the MIDI sys clock implementation seems very dependent on UI activity. To replicate: 1. generate MIDI clock and monitor the BPM. 2. Bring up any effect for edit, and twist one of the parameter knobs thus causing the clock to vary wildly. By itself, this isn't an issue for configuration, however the issue also occurs if you have tied and expression pedal to a parameter controller, and then adjust the expression pedal during play. Using a MIDI controlled delay for instance, while varying a WAH pedal will cause the delay echo to spin out of control. Similarly, using the same MIDI controlled echo, and pressing a snapshot button will have the same effect. From a SW perspective, It's like the MIDI clock generation isn't in a high priority process relative to the UI which can tolerate a few milliseconds of delay. That MIDI clock has be fairly solid otherwise were stuck using a separate generator.
  3. I guess the first questions to ask are, 1. Have you been able to connect to the Helix with another computer? 2. Can you connect a basic USB drive to the Dell and get that to work? 3. You said you say the Helix was seen in the device manager, but are there any yellow triangles appearing with those helix items? Are there yellow triangles any where in your Device Manager related to USB? Take a look at this thread. Don't know of this will help http://line6.com/support/topic/26545-helix-not-connecting-to-pc/?hl=usb
  4. richmaes

    2.20 Party

    Excellent known issue for those that read the release notes... If a user fails to read and follow the update instructions, Helix will engage Snapshot 2 in preset 8 Templates > 32D every day at 4:30 AM
  5. richmaes

    Helix FW 2.20 (The "Get Low" Update) OUT NOW

    The breaking out of MIDI PC send and receive actions is a great feature. I actually ran into that problem when using the Helix with Apple Sound Stage two weeks ago. I ended up writing a Arduino MIDI filter to block the propagation of PC's back to the to application. Guess I'll be able to get my Arduino back soon. Thanks.
  6. richmaes

    Helix to follow Pro Tools tempo

    Is there a preliminary release notes doc that shows all the fixes that will be included with 2.20? Can we see it?
  7. richmaes

    Arduino project to let a Helix control a Voodoo Labs GCX

    So looking at the Midi Solutions Event Processor, it looks like a very full featured solution. The software guide seems to indicate you can do "If this, and then if this, do this" type of commands which is required for this solution. So I think you could do it. The big difference is that the MIDI solutions event processor is about $150 bucks and the Arduino and Midi shield you can get for around $25 without a case. BTW, it turns out that finding a case that fits an Arduino WITH a MIDI shield is not easy. I found a guy who makes a taller transparent plastic arduino box. I have ordered one. I'll repost when I get it.
  8. I came up with this cool solution to control my GCX from my Line 6 Helix, but it could be used with practically anything. To define the problem, the L6 Helix can generate 6 immediate MIDI messages. These messages are pretty flexible as to what you want, but the GCX needs at least 8 CC messages to properly configure it worst case. Also, I don't want to burn all of my immediate commands to control most of the GCX. So I had the idea to create a Arduino project that would take MIDI PC and MIDI Bank Select to produce a 8 bit value which I could then convert into 8 CC messages between CC#80 and CC#87. #UPDATED 2/25/17: I have also added a feature to generate a MIDI clock using channel 16 CC# 00 which is a feature that Helix doesn't currently have right now either. Basically, CC#00 value + 40 is the BPM of the clock, so a CC#00 value == 70 translates to a BPM of 110. Because CC value can only go up to 127, the max BPM is 167. To demonstrate the PC BS conversion process, A Channel 16 PC 77 with Bank select 0 converts to binary 0x4D => Binary 01001101 A Channel 16 PC 77 with Bank Select 1 converts to binary 0xCD => Binary 11001101 Notice that the Bank Select value basically controls bit 8 and the PC value represents bits 6 down to 0. Taken together, they represent a 8 bit value representing the 8 loops of the GCX. Based on the binary output, I scroll through bits 0 to 7 and send messages on CC 80 to CC 87. If a bit is a 1, I turn the loop on by setting the corresponding CC value to 127 and if it is a zero, I set the CC value to 0. The Helix can generate a Bank Select and PC as one message, so for the price of one message, this project will make me 8 CC#'s effectively. This code is hardcoded to channel 16 because, that is the "ONLY" channel a GCX will receive on. This code should allow other messages through, with only the Arduino's SW loop latency. There maybe some other side effects to, but those side effects should be limited to channel 16 PC and channel 16 CC#32. I have tested this on a Arduino UNO board with a Olimex MIDI Shield. // GCX Editor // By Rich Maes // email:r i c h m a e sAThotmailDOTcom // Converts MIDI PC's on channel 16 to GCX CC's starting at 0x80 // Allows everything else to pass. #define MIDI_PC_CH16 0xCF #define MIDI_CC_CH16 0xBF #define MIDI_SYSEX 0xF0 #define MIDI_SYSRT_CLK 0xF8 #define REQUIRE_CLOCK_SETTING 1 boolean byteReady; boolean sendCCMessage; boolean generateClock; boolean disableClockOnNextPC; int ccMsgsToSend; unsigned char midiByte; unsigned char capturePCByte; unsigned char captureCCByte; // unsigned char captureCCMSbyte; unsigned long lastClock; unsigned long captClock; unsigned long clk_period_us; // Queue Logic for storing messages int headQ = 0; int tailQ = 0; unsigned char tx_queue[128]; int getQDepth(); void addQueue(unsigned char myByte); void addCCQueue(unsigned char captureCCByte, unsigned char capturePCByte); unsigned char deQueue(); static enum { STATE_UNKNOWN, STATE_1PARAM, STATE_1PARAM_CONTINUE, STATE_2PARAM_1, STATE_2PARAM_2, STATE_2PARAM_1_CONTINUE, STATE_3PARAM_2, STATE_PASSTHRU } state = STATE_UNKNOWN; void setup() { // put your setup code here, to run once: // Set MIDI baud rate: Serial.begin(31250); sendCCMessage = false; byteReady = false; midiByte = 0x00; state = STATE_UNKNOWN; captureCCByte = 0; // captureCCMSbyte = 0; generateClock = false; disableClockOnNextPC = true; capturePCByte = 0; ccMsgsToSend = 0; } int getQDepth() { int depth = 0; if (headQ < tailQ) { depth = 128 - (tailQ - headQ); } else { depth = headQ - tailQ; } return depth; } void addQueue (unsigned char myByte) { int depth = 0; depth = getQDepth(); if (depth < 126) { tx_queue[headQ] = myByte; headQ++; headQ = headQ % 128; // Always keep the headQ limited between 0 and 127 } } void addCCQueue(unsigned char myCaptureCCByte, unsigned char myCapturePCByte) { int i; if (getQDepth() < 80) { // There is enough space to add our CC messages for (i = 0; i < 8; i++) { addQueue(0xBF); addQueue(80 + i); addQueue(127 * ((((myCaptureCCByte * 128) + myCapturePCByte) >> i) % 2)); } } else { // This is an error condition. So reset the queue and pointers headQ = 0; tailQ = 0; byteReady = false; for (i = 0; i < 128; i++) { tx_queue[i] = 0; } } } unsigned char deQueue() { unsigned char myByte; myByte = tx_queue[tailQ]; tailQ++; tailQ = tailQ % 128; // Keep this tailQ contained within a limit // Now that we dequeed the byte, it must be sent. return myByte; } void loop() { if (generateClock) { captClock = micros(); if (lastClock > captClock) { // we have a roll over condition if (clk_period_us <= (4294967295 - (lastClock - captClock))) { lastClock = captClock; addQueue(0xF8); } } else if (clk_period_us <= captClock-lastClock) { lastClock = captClock; addQueue(0xF8); } } if (byteReady) { if (midiByte >= 0xF0) { // This automatically passes all clocks and System Realtime Messages state = STATE_PASSTHRU; } else if (midiByte >= 0x80) { switch (midiByte) { case MIDI_PC_CH16: state = STATE_1PARAM; break; case MIDI_CC_CH16: state = STATE_2PARAM_1; break; default: state = STATE_PASSTHRU; break; } } else { switch (state) { case STATE_1PARAM: capturePCByte = midiByte; state = STATE_1PARAM_CONTINUE; addCCQueue(captureCCByte, capturePCByte); #ifdef REQUIRE_CLOCK_SETTING if (disableClockOnNextPC) generateClock = false; disableClockOnNextPC = true; #endif break; case STATE_2PARAM_1: if (midiByte == 32) state = STATE_2PARAM_2; if (midiByte == 00) { state = STATE_3PARAM_2; #ifdef REQUIRE_CLOCK_SETTING // We have just update the clock so don't force the next PC to disable // clock generation disableClockOnNextPC = false; #endif } else state = STATE_2PARAM_1_CONTINUE; break; case STATE_2PARAM_2: state = STATE_2PARAM_1_CONTINUE; captureCCByte = midiByte; break; case STATE_3PARAM_2: state = STATE_2PARAM_1_CONTINUE; clk_period_us = 60000000 / (24 * (40 + midiByte)); generateClock = (midiByte > 0); lastClock = micros(); break; default: state = STATE_PASSTHRU; break; } } } if ((state == STATE_PASSTHRU) && byteReady) { // Just pass messages unaltered. Also don't let any of our modified message through if // we are passing though. Our burst of modified CC# can wait. // Serial.write(midiByte); addQueue(midiByte); // state = STATE_UNKNOWN; } byteReady = false; if (getQDepth() > 0) { // We have a byte to send, dequeu and send it Serial.write(deQueue()); } } // The little function that gets called each time loop is called. // This is automated somwhere in the Arduino code. void serialEvent() { if (Serial.available()) { // get the new byte: midiByte = (unsigned char)Serial.read(); byteReady = true; } }
  9. I saw a Line 6 page on https://line6.ideascale.com. Is that the right place to make a feature request for the Helix? Or somewhere else? Rich
  10. richmaes

    Gearbox Is Dead, What A Shame.

    Sorry for bringing up an old post, but I just ran into the Gear Box issue not quite working correctly. Relative to this post from TheRealZap, you say, "there are just other programs." What other programs are you talking about relative to X3 patch editing and X3 tone management?
  11. Same thing just happened to me. I was able to resolve the issue by opening the applications folder and right-clicking over Line 6 Money 1.72 and selecting Move to Trash. After that I manually downloaded Monkey 1.73 and installed. For whatever reason, upgrading from within Monkey 1.72 doesn't seem to work.
  12. richmaes

    Midi Clock Sync!

    One more request for MIDI sync.
×