Jump to content

TK.

Administrators
  • Posts

    15,247
  • Joined

Posts posted by TK.

  1. You are writing "0xfc continuously" - does it mean that there is a delay between each 0xfc (MIDI Clock Stop) event, e.g. 1..10...100 mS?

    Or is it sent without any delay?

     

    Compared to older versions, v1.030 got a MIDI Clock generator which would send 0xfc if it receives the same event from any MIDI IN port.

     

    So: which MIDI device could send 0xfc at your side?

    E.g. any device connected to a MIDI IN port, or maybe your DAW which sends to an USB IN, or could it be related to a feedback loop?

     

    Best Regards, Thorsten.

  2. You are right, "force to scale" is always enabled in grid mode:

     

          u8 use_scale = 1; // should we use this only for force-to-scale mode? I don't think so - for best "first impression" :)
    

     

    So: actually I wanted to achieve that people are starting with the scaled layout without special options when they are using the BLM.

    Do you really need the grid mode w/o FTS? Then I've to make this option configurable...

     

    Best Regards, Thorsten.

  3. I need more input to understand the situation:

    - with "doesn't detect it anymore" you mean the MBHP_MF_NG module?

    - with "port 1" you mean "MIDI IN1"?

    - who/what receives "fc" at port 1, resp. how did you determine this?

    - what is your exact .ngc configuration?

    - anything else special in your setup which would be important to know?

     

    Best Regards, Thorsten.

  4. I'm thinking of writing a raspberry pi/2xnovation launchpad implementation of a Midibox Seq BLM.  I'm thinking I'd use processing in the raspberry pi to emulate a larger set of buttons on the novation launchpads - 2 LP's would be an 8x16 array with two extra vertical rows and one extra horizontal row.  I'd use the second vertical row for a variety of "shift" and modifier buttons which could move the area displayed on the 8x16 LP matrix - default would be to display the top 8x16 section, pressing a modifier would display the bottom 8x16 section.

     

    Is it possible to implement a larger button matrix?  Like, would MIOS support a 32(vertical)x16(horizontal) matrix?  If so, I could set up my software to emulate (and use modifiers to page through) a larger vertical space.

     

    I've found the BLM user manual page and the document at (root)/trunk/apps/controllers/blm_scalar/README.txt 

     

    Is there any other BLM documentation hidden away anywhere that I should look at?  What files in the MIOS source code contain the BLM input/output handlers?

     

    Yes, there are "hidden" implementations of the BLM emulation which have been programmed for MacOS, Juce and Lemur:

    http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Ftools%2Fblm_scalar_emulation%2F

     

    So: three examples which should give you enough informations.

    Please study them before asking the next questions... ;-)

     

    Up to 256x64 matrices are supported!

     

    Also, is there any way (via MIDI) that I could ask the Seq V4 whether force to scale is enabled, and which scale is being used?

     

    The BLM will automatically switch to Force-to-Scale when you enable the option in the MODE page.

     

    So: the BLM will show reduced note space for each track which enabled this mode.

    The scale will be configured in Fx->Scale

     

    It's maybe also worth to mention that the scale will be considered in the vertical directory in Edit mode, and in horizontal direction in Live Keyboard & Record mode.

     

    Best Regards, Thorsten.

  5. What do you think? How about the scanrate in the PIC? Or does the new STM32F4 improve the situation?

     

    That's a complex question which deserves a separate topic! ;-)

     

     

    Finally MIDIbox NG V1.030 has been released with the changes of the last months:

    MIDIbox NG V1.030
    ~~~~~~~~~~~~~~~~~
    
       o increased event pool size to 64k for MBHP_CORE_STM32F4
    
       o added ain_mode=Switch for AIN and AINSER events.
         Can be used if buttons are connected to analog inputs. The event will send the
         min value if a 30% threshold is reached, and the max value if a 70% threshold
         is reached.
         Schematic:  Ground |----o Button o-----> analog input + 10k Pull-Up resistor to 3.3V (AIN) resp. 5V (AINSER)
    
       o .ngr: added "change" command. It works similar to the "set" command, but
         only changes the value, and doesn't generate a MIDI event.
    
       o .ngr: added "set_min" and "set_max" command which allows to modify the
         min/max range of a EVENT
    
       o added new meta events to control the internal MIDI clock generator:
         MClkPlay, MClkStop, MClkPlayStop, MClkPause, MClkDecTempo, MClkIncTempo, MClkSetTempo.
         Example can be found under cfg/test/midiclk.ngc
    
       o added new string formatting items:
         %t to display MIDI clock state (Play/Stop)
         %T to display tempo (BPM)
    
       o added new MClk menu page to SCS to control the tempo w/o dedicated controllers
    
       o fixed AOUT_NG module communication issue if AINSER was used in addition
    
       o added new meta events:
           - CvPitchBend14Bit:<cv-channel>
           - CvPitchBend7Bit:<cv-channel>
           - CvPitchRange:<cv-channel>
           - CvTransposeOctave:<cv-channel>
           - CvTransposeSemitones:<cv-channel>
         see cfg/test/cvtransp.ngc for usage examples
    
       o BUTTON toggle function can now also handle with inverted and reduced value ranges

     

    The user manual has been updated as well: http://www.ucapps.de/midibox_ng_manual.html

     

    Best Regards, Thorsten.

  6. The Ambika project is based on an ATmega 644, which has two internal UARTs (= 2 MIDI IN and 2 MIDI OUT)

    Maybe the option for a second MIDI IN is not prepared on the PCB, but it shouldn't be so difficult to add one (and to enable the second UART in the firmware) - just ask the Author of this project.

     

    Best Regards, Thorsten.

  7. I would like to get some more feedback from other users before release to ensure that most people are satisfied with the changes - resp. are there users who don't like the change?

     

    You could vary the speed for different encoders in CS_MENU_EncSpeedSet - the part which sets the speed depending on the range is clearly separated and therefore easy to change for your needs.

    I'm not planning to provide this as a generic option for all people, because it would increase the complexity for adaptions (e.g. if somebody wants to add more encoders, he would have to do changes at one additional place). And streamlining the encoder configuration to simplify changes would be a huge task at my side.

    Do other users have the same problem like jrp, that rotary encoders need different speed configurations although they control the same range?

     

    This is the wrong topic to reply your additional questions - here we talk about encoder behavior optimizations...

    I would need some time to understand the firmware that I programmed many years ago anyhow to give you sufficient answers... ;-))

     

    Best Regards, Thorsten.

  8. I agree that speed 8 would be nice, on the other hand - as you already noticed - this will lead into more stepiness.

     

    In order to compensate this effect for CutOff, you could activate the FIP option in the FIL menu, which smooths the waveform.

     

     

    New firmware available where encoder behaviour should be much better:

    http://www.ucapps.de/mios/midibox_sid_v2_044_enctest2.zip

     

    • changed encoder speed modes depending on resolution
    • encoders are fast by default, and SHIFT button slows down encoder speed
    • speed of the "menu" encoder now also varied depending on the resolution.
      Especially sammichSID users will like this change

    Please try!

     

    Best Regards, Thorsten.

  9. No problem, MBNG uses almost the same "buffered LCD" handler like MBSEQ, which means that the same method can be copy&pasted into the code.

     

    There is a problem: the messages should only be print temporary, but the buffered LCD handler expects a static screen.

    Changing this would lead to a bad MIDI performance.

    And adding a buffer for this LCD messaging feature at the MBSEQ side would mean less place for more useful features.

     

    Since this would only for you, and since I'm sure that you will find other ways (sending LCD strings via EVENT_ commands), I won't implement this.

     

    Best Regards, Thorsten.

  10. Yes, in conjunction with MBNG you could also add LED rings if you still prefer rotary encoders. Or you could use pots and/or (motor)faders.

     

    Control via SysEx is possible as well of course, but the setup is more difficult, and sending the complete patch takes more time.

    If you are only interested on a high-res CutOff, then send it as a NRPN parameter, and set the appr. LED ring via the CC dump.

     

    Best Regards, Thorsten.

  11. Yes, I read it, and think it makes sense to change the behaviour, so that incoming CC values will also be stored in the edit buffer.

    Only value changes caused by ModWheel, Velocity, Aftertouch, Knobs and Wavetable shouldn't be stored.

    It will be an option which is enabled by default (because I guess that most people will like it), and could be disabled in setup_*.asm (for the minority who doesn't like it).

     

    In addition, I will add a "CC dump request" which will allow to synchronize a MBNG with the current patch CCs.

     

    Behaviour of SHIFT button will be configurable as well, and switched back to the original "slow" switching like in pre-42 releases.

     

    Back to topic: help to find best matching speed parameters, please! ;-)

     

    Best Regards, Thorsten.

  12. In this case I would propose that you try the testmode in the new firmware.

    Help to find better matching values and give feedback about your thoughts.

     

    With good settings the value range shouldn't matter, it should always feel "good" and "usable".

     

    For encoders I don't really see an advantage if I would try to translate a relative or passthrough (resp. "snap" or "soft-takeover") mode.

    This wouldn't solve the problem that we actually only need better speed parameters.

     

    Best Regards, Thorsten.

  13. Of course, it will get motormix values over USB2 since you've configured it as the "config_port".

    I assume, that you get the CC/Pitchbend via USB1, right?

     

    Select another "config_port" for configuration purposes which isn't used by your DAW.

     

    Best Regards, Thorsten.

×
×
  • Create New...