Jump to content

TK.

Administrators
  • Posts

    15,193
  • Joined

Posts posted by TK.

  1. Interesting timing of this posting: recently I noticed a very similar problem and hacked a quick change into the firmware to move forward.

    Let's make it official :-) -> http://www.ucapps.de/mios32/midibox_seq_v4_098_pre1.zip

    From the ChangeLog:

    MIDIboxSEQ V4.098
    ~~~~~~~~~~~~~~~~~
    
       o Phrase Mode: if Option 3/33 "Pattern Change Synchronization" is activated, patterns will start
         from step 1 after song position change. This is especially useful if phrases contain tracks
         with different lengths.
         Option 5/33 "Restart all Tracks on Pattern Change" should be disabled in this case because
         it won't lead to the intended results.
    

    Best Regards, Thorsten.

    P.S.: I removed your first posting because it seems to be a duplicate

  2. Hi Christian,

    I agree that your keyboard doesn't handle Note-Off messages correctly. According to the MIDI Spec (-> https://web.archive.org/web/20071005165318fw_/http://www.borg.com/~jglatt/tech/midispec/noteoff.htm ) the default velocity should be 64 if not supported, but it sends 0 instead. Your other keyboard sends 127, which is actually also wrong if it doesn't support this feature - but somehow works better.

    Actually it's recommended that keyboards send Note On with velocity 0 to turn off the note, because this keeps the runtime status, ensures that no extra byte has to be sent out and therefore saves some time (ca. 320 uS)

    Behringer Neutron: either sets a very long release time (e.g. for VCA envelope) with Note Off Velocity 0, or it doesn't handle Note Off correctly -- 0 is a valid value and if there is no special processing for this velocity value, it should be handled like any other.

     

    Quote

    Second question: can I use MidiBox to receive MIDI commands, send the good ones and correct the bad ones, or would that create huge latency?

    This would add +1 mS latency, which is acceptable.

    Best Regards, Thorsten.

  3. Hi Bartosz,

    the entire history is in github, which means that in your downloaded repository you could switch back to the sources which were used for v1.036

    The appr. commit was 6edfcd51ad6cb78f83d6094c5c9d1b7c5b85ddb3
    So, just enter "git checkout 6edfcd51ad6cb78f83d6094c5c9d1b7c5b85ddb3" to switch back.

    There are also ways to compare the "good version" with the latest one, e.g.: https://github.com/midibox/mios32/compare/6edfcd51ad6cb78f83d6094c5c9d1b7c5b85ddb3..master

    Or you could clone the repository two times, switch one to the good version, and then use a diff tool such as "beyond compare" to analyze the changes:

    image.png

    image.png

    Best Regards, Thorsten.

     

  4. Hi,

    you could send values from the Tick() hook - by using a static variable you can ensure that the values will only be sent once after startup.

    Something like this (untested code)

    /////////////////////////////////////////////////////////////////////////////
    // This function is called by MIOS in the mainloop when nothing else is to do
    /////////////////////////////////////////////////////////////////////////////
    void Tick(void) __wparam
    {
      static unsigned char ain_sent = 0;
    
      if( ain_sent == 0 ) {
        unsigned char pin;
        unsigned char num_ain = MIOS_AIN_NumberGet();
    
        ain_sent = 1; // only sent once after startup
    
        for(pin=0; pin < num_ain; ++pin) {
          MIOS_MIDI_TxBufferPut(0xb0); // CC at channel 1
          MIOS_MIDI_TxBufferPut(pin);  // pin number corresponds to CC number
          MIOS_MIDI_TxBufferPut(MIOS_AIN_Pin7bitGet(pin));
        }
      }
    }

    Best Regards, Thorsten.

  5. (Almost) well done! :)

    Quote

    Some unexpected high notes.

    I would propose to define a 13th step (at position #12) which transposes by +0 (-> no transpose), and to set the loop point there. This ensures it won't be transposed further.
    Alternatively try Oneshot mode.

    Quote

    In Wavetable 2, I want the Triangle Waveform to play on each of the 12 steps. So in hexidecimal it should be a value of 01 on each step?

    yes

    Quote

    It could also be an issue with my MB-6582 causing unexpected behavior, I need to resolder joints as I get some noise at times.

    Are you using this PSU? https://www.c64psu.com/c64psu/43-commodore-64-c64-psu-power-supply.html#/37-ac_cable-eu

    I noticed that the 5V output sometimes only delivers ca. 4.5V, which is too low and can cause random glitches. Also display backlight becomes darker. Power-cycling the PSU normally helps to get it stable again.

    Best Regards, Thorsten.

    P.S.: I will move the wavetable topic to a separate thread, because it's unrelated to the Ctrlr Panel

  6. The links listed here: http://ucapps.de/midibox_sid_manual.html are working at my end - which page do you mean exactly?

    Yes, I'm aware that WTs are harder to program. People have to learn hexadecimal numbers... a good GUI design could hide this complexity and make WTs more accessible, but 1) Ctrlr limitations have to be considered and 2) it has to be consider that actually 4 wavetables are available with inididual start/end/loop point which can be anywhere in the 128 steps table.

    If you limit such features just to simplify the GUI (like in Insidious), it would mean that WTs in some patches can't be edited properly. Hence we need a solution which is easy to use and universal enough.

    Concerning usage examples: did you already find the "first steps" guide - search for "Wavetable Sequencer": http://ucapps.de/midibox_sid_manual_fs.html

    There are also some legacy tutorials for MBSID V1 which show how to work with arpeggios:

    Best Regards, Thorsten.

     

  7. Thank you both - as you noticed, I'm solving some topics, but please don't expect too much in the next months, I just want to ensure that we are still able to play with our MIDIboxes (and of course enhance them) the next years :happy:

    On 10/26/2023 at 10:26 PM, Smithy said:

    Have you any plans or even the time to finish the Wavetable Editor for the Ctrlr panel?

    Need some time to think about this - The MBSIDV2 WT handler offers much more flexibility than the Reaktor based solution, and such a nice looking GUI won't be possible to implement with the given capabilities of Ctrlr. So, it's already clear: if I come up with a solution, it will be very pragmatic... :veryhappy:

    Best Regards, Thorsten.

  8. Interesting! You are totally right, and it seems that nobody complained about this before, resp. if so it didn't raise my attention ;-)

    It's fixed now, please try: http://www.ucapps.de/mios/midibox_sid_v2_046.zip

    I think that I should also release this version, the official one is v2_044, but some minor changes have been done in the last years so that it's worth to make it available for everybody who uses the pre-built version.

    Please let me know if it works with your hardware.

    Best Regards, Thorsten.

  9. Ok, I've to admit that I haven't checked the current state of the driver before my reply

    Unfortunately it isn't available - last posting about this activity was more than 10 years ago: 

     

    I fear that nobody can help you to get it running :-(

    Best Regards, Thorsten.

  10. Yes, this one should work

    Here the interconnections: http://www.midibox.org/dokuwiki/lib/exe/fetch.php?media=neonking:ssd1322-pinout.jpg

    In order to select the display in MIOS32, upload the Bootloader Update Application and enter:

    set lcd_type GLCD_SSD1322
    set lcd_num_x 1
    set lcd_num_y 1
    set lcd_width 256
    set lcd_height 64
    store

    Thereafter upload the MIDIbox NG application again -> display should show some meaningful messages

    Best Regards, Thorsten.

  11. Hi,

    in the last days I troubleshooted the MIDIbox SID panel with the latest CTRLR sources which are available on Github.

    This resulted into:

    I will do some testing in the next days to ensure that all parameters are working, and I have to find a way to build AUs

    However, I will only be able to provide a MacOS version. PC users might be interested on the "fixed version" as well.
    Therefore the question: has anybody the knowledge to build CTRLR with my source code changes on a PC?

    Best Regards, Thorsten.

  12. There is hope! Two days ago a new JUCE version has been released with an interesting message:

      #if ((defined (MAC_OS_X_VERSION_MIN_REQUIRED)                                \
            && MAC_OS_X_VERSION_MIN_REQUIRED < MAC_OS_VERSION_13_0)                \
           || (defined (__IPHONE_OS_VERSION_MIN_REQUIRED)                          \
               && __IPHONE_OS_VERSION_MIN_REQUIRED < __IPHONE_15_0))
       // This is an error because the linker _will_ produce a binary that is
       // broken on older platforms
       static_assert (std::string_view (__clang_version__)
                          != std::string_view ("15.0.0 (clang-1500.0.40.1)"),
                      "The new linker introduced in Xcode 15.0 will produce "
                      "broken binaries when targeting older platforms.\n"
                      "To work around this issue, bump your deployment target to "
                      "macOS 13 or iOS 15, re-enable the old linker by adding "
                      "'-Wl,-ld_classic' to your link flags, or update to Xcode "
                      "15.1.\n"
                      "Once you've selected a workaround, you can add "
                      "JUCE_SILENCE_XCODE_15_LINKER_WARNING to your preprocessor "
                      "definitions to silence this warning.");
      #endif
     #endif

    So, here a new binary build with latest JUCE and -Wl,-ld_classic flags, let me know if this works:

    -> http://www.ucapps.de/mios_studio/MIOS_Studio_2_4_9_r3.app.zip

    Best Regards, Thorsten.

  13. Hi Zam,

    thanks for the feedback - although it worries me ;)

    The crash report indicates that something is going wrong before the actual application code has been started.
    I haven't seen this before, and therefore don't have a solution (yet).

    What would be interesting: what happens if you start MIOS Studio from a terminal:

    MIOS_Studio.app/Contents/MacOS/MIOS_Studio --batch

    Best Regards, Thorsten.

  14. In the past I requested to use gcc-arm-none-eabi-4_7-2013q3-20130916 for compiling MIOS32 applications to ensure that there are no unexpected incompatibility issues. This version is still recommended (although it's already 10 years old) and can be downloaded from: http://www.midibox.org/mios32_toolchain/

    However, newer machines might not run with these binaries anymore, such as Apple Silicon based Macs. Therefore I tried the latest arm-gnu-toolchain-12.3 which can be downloaded from: https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads and can confirm, that this version is working fine without adaptions :)

    Best Regards, Thorsten.

  15. Under http://ucapps.de/mios_studio.html we can now find a re-released version for MacOS which natively supports Intel and Apple Silicon (M1, M2, ...) based HW without the need to run Rosetta2

    This change required to switch to the latest JUCE 7.0.7 version

    However, there are no functional differences, and especially no new MIOS Studio features (currently nothing new planned for this tool)

    Best Regards, Thorsten.

  16. I remember that I added STM32F1 support on a "good will basis" without continuous testing, therefore it's not officially available (means: you've to try it, and if it doesn't work anymore, roll back to a working version)

    Limitations:

    • only 24k instead of 64k configuration memory (.NGC file)
    • .NGR files are directly processed from SD Card and not from RAM, which means that such scripts are much slower - however, as long as NGR files are not processed by your use case, or only sporadically used, no real impact on the overall performance
    • only 1 DIO port:
      // STM32F1: J5A+J5B
      // STM32F4: J5A+J5B, J10A, J10B
      // LPC17: J5A+J5B, J10, J28
    • only 6 (instead of 8) direct AIN inputs
    • only 3 UART based MIDI IN/OUT (instead of 4)

    Best Regards, Thorsten.

  17. It looks correct when I compare with the code, and actually it seems that the comment is wrong:

          // BLM_X DOUT -> GP LED mapping
          // left/right half offsets; green,red
          // 0 = 8,9        1 = 11,10       2 = 13,12       3 = 15,14
          // 4 = 40,41      2 = 43,42       3 = 45,44       4 = 47,46

    should be:

          // BLM_X DOUT -> GP LED mapping
          // left/right half offsets; green,red
          // 0 = 9,8        1 = 11,10       2 = 13,12       3 = 15,14
          // 4 = 41,40      2 = 43,42       3 = 45,44       4 = 47,46

    So, 0 and 4 follow the same "swapped order" like other Duo-coloured LEDs.

    do you agree?

    Some additional hints:

    • the relation between row M1..M8/column 0..7 and the 74HC595 output pins can be confusing - many people connected the pins in mirrored order in the past - be careful about that, otherwise the GP pin assignments have to be changed in the source code (-> you will need a local build).
      Wilbas schematic is a good reference in which order data lines have to be connected
    • 1st and 2nd color (typically "red" and "green") can be swapped during runtime in the Options page
    • for all other LEDs the assignment doesn't matter because they are free configurable in the MBSEQ_V4.HW file - you can try out once the front panel is working

    Best Regards, Thorsten.

×
×
  • Create New...