TK.

Reverse engineering a protocol for private purposes is one thing, publishing the information another. In any case: please don't publish any specific information about this protocol in this forum, this could bring me (as the forum owner) into serious legal issues! Best Regards, Thorsten. P.S.: I haven't looked into this protocol because I don't like the license. Anything which can't be openly published isn't interesting for my projects.

It's unclear if I should really spend some more time to work on this. If I understood @weasel correctly, he sees a path via Arduino based solutions which he would prefer. In this case my contribution wouldn't add any value... just follow him. Best Regards, Thorsten.

Impressive work! The WS2812 driver was only a quick hack, I was already satisfied after it was working and haven't expected that somebody would ever drive more than 50..100 LEDs. It shouldn't be a big deal to optimize the memory consumption. There are various places in MIOS32 where I already used DMA double buffers (e.g. I2S audio output). Nothing needs to be explored, just translation :) Best Regards, Thorsten.

Yes, each RGB LED will consume 48 bytes. With the latest changes up to 390 RGB LEDs can be defined, and you will get a proper RAM error message if there are too much, such as: /opt/gcc-arm-none-eabi-4_7-2013q3/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/bin/ld: project_build/project.elf section `.bss' will not fit in region `RAM' /opt/gcc-arm-none-eabi-4_7-2013q3/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/bin/ld: region `RAM' overflowed by 424 bytes collect2: error: ld returned 1 exit status Best Regards, Thorsten.

Hi, STM32F4 was running out of memory - and due to an wrong linker file entry you haven't got an error after the 128k boundary of the "normal RAM" has been touched. However, this chip has some additional 64k as a so called "core coupled memory", which is located at 0x10000000 I changed the linker file and preload code to support this memory. In addition, in the MBNG application I moved the heap memory into this CCMRAM, giving us about 10k more space. Updates are available at github: https://github.com/midibox/mios32/commit/9dc48579c31766815997b0ce3eac88f9d772578a I havent't checked if this has a new negative side effect, but at least MBNG is booting and RGB LEDs are working Best Regards, Thorsten.

Source code is here: https://github.com/midibox/mios32/tree/master/apps/sequencers/midibox_seq_v4 Beat Light is controlled in src/seq_ui.c: https://github.com/midibox/mios32/blob/master/apps/sequencers/midibox_seq_v4/core/seq_ui.c (search for BEAT) The problem is understood - it appears on frontpanels with single colour LEDs (MEASURE not assigned). However, a quick fix is easy: just replace SEQ_LED_PinSet(seq_hwcfg_led.beat, (seq_hwcfg_led.measure && measure_led_on) ? 0 : beat_led_on); by if( seq_hwcfg_led.measure != 0xffff ) SEQ_LED_PinSet(seq_hwcfg_led.beat, (seq_hwcfg_led.measure && measure_led_on) ? 0 : beat_led_on); else SEQ_LED_PinSet(seq_hwcfg_led.beat, beat_led_on); Untested code Please let me know if it works, so that I will bring it into the repo Concerning mirrored Roll parameter: that's normal if the parameter layer is only 16 steps. It's due to a memory limitation - drum tracks can only store 1024 parameters, and they are partitioned over the number of drum tracks and parameter layers Best Regards, Thorsten.

The workflow can be much easier: just clone the worktree, create a branch, commit into this branch how often you want, push to GitHub whenever you want to ensure that your work doesn't get lost (and want that other people can access your changes). There are various tools to display code changes between branches, between your commit, etc. also locally without the need for a webserver. E.g. I'm using "gitk", but there might be many others. But uploading to GitHub is preferred - not only for backup reasons, but also to allow later merging into master branch via pull request + review from my side. Best Regards, Thorsten.

Hi, actually environment variables are "local" in your shell. Which means, if you open multiple shells you can set the variables to different values in order to work on multiple projects in parallel. Build objects are created locally in your app folder as well. Or you could create a small shell script which sets the variables before calling "make" - this way you could work from a single terminal. Or you quickly switch between the setups by sourcing one of the "source_me_*" files in the base directory: https://github.com/midibox/mios32 Of course, it's also possible to create different GIT clones which makes sense if you work in separate branches for each activity. Best Regards, Thorsten.

@Digineuralthanks for the info! I've to explore Dockerfile, it promises high potential :) @Phatlineunfortunately I don't understand the problem, I haven't provided the package as a "rar" file, and the binary works with various Linux installations that I tried so far. There seems to be something wrong with your OS installation (maybe you are using an expert system?), but I fear that I can't give you more hints. @Elektruckas long as you are the only Win10 user who has this problem with SD Card uploads I won't start to analyze this. MIOS Studio 2.4.8 is released now @ http://www.ucapps.de - let's see if additional users report problems; the legacy 2.4.6 files are still accessible from the same page to ensure that nobody is blocked by the progress (only 64bit systems supported anymore) Best Regards, Thorsten.

Yes, 64bit only. The MacOS build should show the same functionality and robustness like 2.4.6, therefore you won't miss anything on your older computer :) Best Regards, Thorsten.

You can achieve similar things with the duplication Fx, see http://ucapps.de/midibox_seq_manual_m.html (search for Fx Dupl) It isn't so flexible like this app, but at least you can define the number of channels (= voices) + the first channel. Either select alternate or random channel mode. Works also well with echo Fx btw :) -> mbseqv4_demo_dupl_fx.mp3 Best Regards, Thorsten.

This was a long journey - jumping between three computers to ensure a consistent reproducible build state in the repository (which is now hosted at Github) Please try: MacOS: http://www.ucapps.de/mios_studio/MIOS_Studio_2_4_8.app.zip Linux: http://www.ucapps.de/mios_studio/MIOS_Studio_2_4_8.tar.gz Win10 64bit: http://www.ucapps.de/mios_studio/MIOS_Studio_2_4_8.zip Best Regards, Thorsten.

No, I moved because I noticed that your MCAN activity doesn't really fit with the subversion work flow anymore. ;) yes Best Regards, Thorsten.

Hi *, The MIOS repositories are now hosted at Github: https://github.com/midibox/mios8 https://github.com/midibox/mios32 This should improve collaboration in future, because branching in GIT is much easier. It's not possible to access the old subversion repositories via SSH anymore, in future changes can only be pushed into the new GIT repositories. There are tons of documentation how to use GIT on the web, therefore I won't repeat this here. ;) Just want to mention the general workflow: we use a simplified workflow without develop branch, so: master is the latest everybody who want's to contribute has to create a feature branch, e.g. feature/my_project once you are fine with your changes, create a pull request from your branch into master, and set me as a reviewer I will review your changes, and if they are fine I will integrate them into master meanwhile everybody is able to work with your changes by switching to your feature branch Currently we've only one branch: feature/mcan (from Bruno) How to contribute: create a github account (if you don't already have one) register your SSH key in the profile inform me about your account name so that I can add it to the midibox project now you can clone the repository with git clone ssh://git@github.com/midibox/mios32 Within this repository you can create a branch with: git checkout master -b feature/<your-branch-name> You can commit changes with git commit . resp. "git commit" if you've indexed the files with "git add" before You can push committed changes to github with git push If you are working from a fresh clone, use "git checkout feature/<name>" to select your feature branch With "git branch -a" you will get an overview about the branches. There are also various GUIs available to display changes in your local repository, e.g. I prefer "gitk" Best Regards, Thorsten. P.S.: Wiki and ucapps documentation will be updated in some weeks once the new workflow is settled ;)

Track information is stored in the bank files (MBSEQ_B1.V4 .. MBSEQ_B4.V4) in "compressed" binary format. You won't be able to decode them directly. But you could export a track as a preset, this will decode the binary and store in readable (and editable) text format. After edit just import back to take over the modifications Best Regards, Thorsten.

I don't plan to change the theme, because I like it as it is. Please don't expect so many changes from my side - I spend my time to migrate to latest Juce version, that's all. Best Regards, Thorsten,

Hi, just would like to let you know, that I started to migrate MIOS Studio to the latest Juce version (5.4.3) - previously we used a pretty old one (I even don't remember the version number) which doesn't work properly with newer OS versions such as Windows 10. The hope is, that the update will solve these issues - if not we had no luck (I won't spend much debug effort there...) Best Regards, Thorsten.

This is what I tested: MIDI menu: Bus1 listens to Bus4 (but All would work as well) and Channel All; Mode: Jam Mixer menu, Page1 (MIDI Port): selected Bus4 In same menu, press SHIFT and GP9 (CC1) - this will allow you to configure the CC numbers sent by CC1 layer Event menu: one layer configured for CC, CC number could be configured but you can also leave it "off" - in this case the incoming CC number will be taken over during recording Enabled Live Record + Live function Back to mixer page #9 (CC1): turn knob to send CC, it should be recorded Best Regards, Thorsten.

Yes, this is already possible: press MENU+Metronome button Best Regards, Thorsten.

Good point! Intuitively I would send the CCs from the mixer, but I noticed that the forwarding path to the bus wasn't implemented. It's available now -> try this version: http://www.ucapps.de/mios32/midibox_seq_v4_096_pre5.zip o the MIDI mixer can now send CC values to a bus. This especially allows to record CC changes (configure MENU->MIDI->Port accordingly so that it listens to the bus in Jam mode) Best Regards, Thorsten.

Hi Jingo, thanks for the compliments! :) Note appears in PA: by default PA plays C-3 on all steps but gate is disabled, therefore you don't see this note. If you enter a note in PE first (intention is that you start with PA), the default C-3 note will be visible in PA. I've to check if this special case could be handled better, on the other hand somebody could have entered this note in PA by intention and wants that it will be played together with the note in PE To the arps: whenever the sequencer is started and no arpeggio pattern has been entered, a C major chord will be played. If you don't want that no notes will be played if no chord is entered, disable the "hold mode" with MENU->Mode, GP9 Best Regards, Thorsten.

Alright, this is now much better to review, I just need to enter "meld branches/mcan trunk" and get a nice graphical diff + merge function. Some first observations: mios32_can.h and mios32_can_midi.h define types which are not in the mios32_* namespace, which could collide with types defined at higher SW layers. Therefore please add the mios32_ postfix to all types which are visible in these header files how to you handle collisions? If two cores send a frame with the same ID concurrently, the arbitration will pass and the remaining frame might collide (e.g. due to different data being sent). The CAN nodes won't automatically re-send the frames. This situation could be avoided if you ensure that each core sends unique IDs, e.g. bring source and destination node into the ID. I guess that you considered this for extended frames, but this format isn't enabled by default... you should do this. mios32_can.h: MIOS32_CAN_VERBOSE should be optional (#ifndef MIOS32_CAN_VERBOSE) and disabled by default you can change the copyright notice to your name (I'm not the creator of this part, you are! :) Best Regards, Thorsten.

First google hit: https://articles.assembla.com/using-subversion/getting-started/branching-and-tagging-in-svn I just tried: svn copy svn+ssh://svn@midibox.org/mios32/trunk svn+ssh://svn@midibox.org/mios32/branches/my_activity it works: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Fbranches%2F You then set MIOS32_PATH to branches/my_activity (resp. the name of your branch directory) instead of trunk Note that this branch looks like a complete copy, but actually it's only a reference on the server, which we will delete once we are happy with the changes and merging has been done. Your changes are still documented in the history. Best Regards, Thorsten.

Hi Bruno, alright, I see... many changes ;) I won't be able to sort this out the next two weeks due to limited time. Would it be possible that you create a minimal update branch until then which is easier to review? This would simplify the work at my side. Once you did this, you could add your local changes again to the official version (they should be taken over separately) Best Regards, Thorsten.

Hi, that's fine! :) The original sources of uCApps.de can be found in the mios subversion repository: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fucapps%2F You could just send me your edits, and I could upload them. If you (or somebody else) is doing changes more frequently, and don't have access to the repository for direct access yet, I could give permission. Publishing is still in my hands (means: if something is wrong, I would correct it). Best Regards, Thorsten.