• Content count

  • Joined

  • Last visited

Posts posted by Hawkeye

  1. @Phatline very good! I am not an electrical engineer, but am now almost convinced something was floating - once you connected the MIDI OUTs to other synths, GND might have crawled onto the case ground, then into the modded switch (screwed to the metal case), from there back into JPA0 and left the MCU in bootloader hold mode, when a cable was plugged into an OUT during bootup.

    Cheers and have fun! :cheers:

    (If it works now, no need to destroy a perfectly good cable, the poor thing! :))

    Many greets,

  2. Cool idea with the mod to add an external bootloader hold switch on JPA0! For it to work, you'd need to install R101/R102 as well.

    Because that's not standard and we had not tested it, i have the itching feeling, that somehow the LoopA could get stuck in Bootloader hold mode for any reason, when a MIDI OUT cable is plugged in (and connected to a synth/ground) during power up. The behaviour with it starting fine without a MIDI OUT cable installed just looks like it. @latigid on - without R101/102 installed and the external switch maybe connected to case ground and that maybe connected to MIDI OUT ground, do you believe there might be something floating, locking the MCU in bootloader hold at startup? @Phatline, could you just try to install those two resistors to see if it helps? Or temporarily remove the switch? It's a long shot :)

    If that does not help, if possible, please proceed with the other suggestions/tests, i'd be particularly interested in power draw and if your 5V rail is good (something like 4.75V or so is ok).

    Many greets,

  3. PS: is J15_S set to 3.3V? Driving the OLED with 5V might work without visual problems, but could contribute to a higher current draw of the LoopA - to me, it feels the problem could be power (or USB cable) related, especially after you said you had problems powering it with your Lenovo T440p - i've got a T460p and the LoopA works flawlessly on every USB port, would not believe the differences of those laptops are dramatic, that's why i wonder if your LoopA is drawing too much current. If you don't have a USB power meter (as per first suggestion), could you try to rig up a measurement with your multimeter? This might mean you'd have to sacrifice a USB cable potentially, but this cable could then be used for power measurements of other devices, too :). You'd need to dismantle the USB cable somewhere in the middle, cut the red (+5V) wire and connect your multimeter in "amps measurement" mode in between.

    Many greets!


  4. @Phatline now, that's a mystery - we'll find the culprit. As a bit of hopeful relief - during the dev time, i tested the LoopA on around 30 synths over here (MIDI OUT function) -> no problems with any of them.

    Let's narrow it down - a few ideas, in no particular order, just brainstorming:

    * do you have a USB power meter available? It shows the voltage of the USB bus and the power consumption of the connected device. You should measure quite close to 5.00V and a consumption of 0.50 amps, if the matias keys are illuminated. If the voltage is significantly lower or the current is higher, then something is wrong. When the case top is off, you could also measure 5V with a multimeter and check if it is significantly below 5V.

    * could you double check if you used 220R resistors near the OUT1-3 ports?

    * could you try to swap your USB cable? I've had bad cables causing strange problems, basically as the LoopA draws 500mA, you should also be able to detect this kind of problem with a drop on the 5V rail (first test)

    * could you remove the LoopA from its metal case and see if the problem persists (a long/uncut pin on the Core PCB could theoretically touch the case bottom and might cause a short?)

    * is the problem only occuring with any MIDI OUT connected to cc-looper/NordRack III or could you reproduce the problem happening also with other synths?

    * related: is the problem only occuring when the connected cc-looper/NordRack III devices are powered, or also when they are powered off? Is it also happening when they are powered off and not connected with their power cable to AC mains?

    * is the problem also occuring, if you power the LoopA via a USB power bank (no connection of the LoopA to AC mains supply)?

    * is the problem also occuring, if you remove the SD card from the LoopA and it enters testmode?

    * is the problem also occuring, if you flash the LoopA e.g. with MIDIbox MBNG (STM32F4 variant?)

    Just saw that Andy was quicker and posted a few other ideas - i think we should be able to figure this out.

    Many greets and have a good evening!

  5. Thanks for the report, Mike! Very good yours is up and running now, cheers :cheers:!
    Regarding the missing parts: in theory, they should be all counted and correct, but you're absolutely right, when i filmed the video tutorial, i still had the preproduction/prototype metal case with large drill holes, thus i used M2 washers on the bottom of the case, which was unfortunately also documented like this in the video...

    These M2 washers at the case bottom are not really required for the final production metal case version and i've updated the video description and added a "youtube card" at the respective time to let builders know! Thanks a lot for the info!

    All other M2 small parts counts should be ok, i painstakingly compared the build video with the parts lists and had written down how many parts are needed for which case variants. E.g. for the M2 nuts, you should have received 9pcs in the LoopA PCB fastening hardware bundle - the parts counts are also visible here:


    Anyways: sorry for the inconvenience!

    Regarding the sandwich and that it's all sometimes a bit fiddly with the M2 screws: yes, you're right, but also that was intentional, we wanted to create a very small form factor triple-PCB-sandwich DIY project, that can compete with the case depth of commercial products (e.g. the LoopA is i think a bit "thinner" than a Machinedrum :)). Assembling it is also good for hand-eye coordination training :).

    Regarding the bootloader jumper JPA0 - it should not have mattered if you left the jumper on, this still needs resistors R101 and R102 to be operational - the idea was to solder in the jumper header in case of a bad app upload - then you could top-solder R101 and R102 (not so easy for the JPA0 headers, this would need uninstallation from the case) and stick in a jumper to be able to trigger the bootloader hold mode. We left out the resistors because they should normally not be needed, but we had the "leftover" jumper for JPA0 anyways and decided to mount it, even if it is normally not used (and needs further resistors to operate).

    Looking forward to your timelapse video, thanks a lot for your efforts there!

    Enjoy your new LoopA and best regards from hot south-of-Munich!


  6. @tago fully agreed!

    Looked into it a bit more, I think it is probably a simple linker config setting that is different between Mac/Linux/Windows - e.g. the newest LoopA version accesses a 64KB RAM block of core-coupled memory available on the STM32F4. When building on Linux, the extra RAM usage is put into the "data" segment, which is wrong:

    arm-none-eabi-size project_build/project.elf
       text    data     bss     dec     hex filename
     220080   59040  123592  402712   62518 project_build/project.elf
    20000000 D __ram_start
    2002c968 B __ram_end

    This will crash the app, but it can be recovered from bootloader hold.

    On a Mac build, the extra RAM used properly goes into the bss segment and a ram_start_ccm linker memory region appears that is used:

    arm-none-eabi-size project_build/project.elf
       text    data     bss     dec     hex filename
     220112    1440  181192  402744   62538 project_build/project.elf
    10000000 B __ram_start_ccm
    1000e100 B __ram_end_ccm
    20000000 D __ram_start
    2001e868 B __ram_end

    This then executes fine on the STM32F4 - if anyone (e.g. @TK. ?) knows what's the culprit, please shout - i'd otherwise investigate when there is a bit more time.

    Many greets,

  7. @j4ustin ok, just tried to reproduce it over here and currently cannot do it.

    My test setup: I've used a phone charger USB power supply (no connection to a computer) and a MIDI Interface connected to the LoopA DIN outputs and measured the MIDI clock received on the MIDI interface via MIDI-OX (via MIDI Sync Transport) on a computer. 

    Tested DIN OUT1-3 this way and can confirm that the clock is sent on every output port only once, i.e. setting to 100 BPM was shown as such in the MIDI-OX Sync Transport Screen. Then tested every port individually and finally removed MIDI clock being sent to the DIN ports, this resulted in no MIDI clock sent to OUT3, which is different than what you encountered.

    Therefore, more info would be required to be able to reproduce the problem:

    a) Which LoopA software version are you running? If you're not yet using v2.06, could you try that?

    b) did you connect anything to the DIN MIDI IN1/2 or the USB input of the LoopA? If something (e.g. a DAW via USB) is connected, that might either generate an own clock or echo back the original clock to the LoopA - this might then explain a multiplication of the clock. If anything is connected on any input, could you try to disconnect all inputs to the LoopA and test again and see if the clock still is multiplied?

    c) related: do you have any MIDI Router routes set up? Do you have any tracks with live forwarding set up? If so, can you try to disable the MIDI routes and the live forwarding to see if the problem stops?

    We should be able to narrow it down and find the problem, thanks a lot!

    Best regards,

  8. @tago as far as i understood, more RAM was required to drive new WS2812 LEDs, e.g. for LED-ring applications with hundreds of LEDs. 

    As NG already requires some RAM, this then required access to the "high memory" part of the STM32F4 - its main memory is segmented in a 128kb main memory and a 64kb ("high mem") block. I guess your old NG apps that still work well don't have this addition (number of supported LEDs increased). Our toolchains in Linux and Windows seem to have trouble building an app like that - i'd guess it must be something simple like a compiler flag or such.

    As a solution for you and if your app does not depend on these LEDs, you could look for the git commit raising the number of these LEDs and reverting it back (just for your own app, of course). It would then require less RAM and should work again when built on Windows/Linux. Not guaranteed though, but maybe worth a try :).

    But this is of course no good solution - so, if someone is able to find out why it won't work under Windows/Linux (e.g. by looking at the differences to the Mac toolchain), this bit of insight would also be highly welcome from my side, as i currently need two machines for building apps that require more than 128kb of RAM :).

    Many greets,

  9. @tago, no problem! The bootloader hold should work, but if you have an ST-Link, that is perfect as well.

    Strange it does not work under windows, too. I've not set up compilation on a Windows box yet, can only state that i have the problem under Linux and that's why i currently have reverted to a MacOS compilation machine (which was standing around doing nothing anyways :)). Sorry, can't currently say what's causing it, other than that i would also very much like to know why it is happening and that you could solve it probably with compilation on a MacOS box.

    Best regards,

  10. @tago which OS did you compile on? Might it be linux? If so, I have a similar problem with the linux toolchain - i believe this happens because the NG project uses "upper memory", the extra 64KB of RAM that is available on the F4s. Somehow currently the Linux toolchain produces an executable that won't run, at least for me.

    If you compile your modified app with the toolchain on MacOS (or i also believe on Windows), all is right.

    Suggestion to solve your problem right now: jumper the core to bootloader hold, then MIOS Studio sees the core in bootloader mode, then reupload either the NG version from ucapps.de or a version self compiled under MacOS. I've yet got to find out what causes the problem with the Linux toolchain, if anyone has any clues why compilation of apps using this upper memory segment is problematic there, please shoot :).

    Hopefully this was at least a bit helpful, even if it is not a full solution.

    Many greets,

  11. @srmaietta - no problem at all, it happened before! :) It should also be an easy fix - the easiest way to remove the resistor network is by using a hot air rework station (around 40€, if you don't have one, google for "858D" :)). When doing that, make sure to heat up the pins until you can see the solder "liquify", then use small SMT tweezers to pull the part off the board, not using too much force - it should go easily, once everything is hot.

    Best regards!

  12. @audiomobster no problem! Could you check, if you maybe have a SEQ v4 FX" Echo Effect" active? This could trigger double (or multiple-echo) notes. If not, then it might also be something on the Blofeld, i.e. a retriggered Amp Envelope? To make sure you have no MIDI echo, you could move the track from the standard DIN MIDI OUT (SEQ OUT1) to a USB MIDI out (SEQ USB1), connect it to a computer and watch the notes that are sent from the SEQ e.g. within MIOS Studio - this would show, if duplicate MIDI notes are generated by the SEQ.

    A MIDI loop usually requires a closed cable loop, i.e. notes coming from an IN going to an OUT on one unit (e.g. the SEQ), and the same happening on the other unit (e.g. a Synth), then there would be a MIDI packet storm that completely saturates the MIDI line :).

    Many greets,

  13. @Made In Machines no problem, we surely want to do a new tutorial, but it's just a lot of work and Andrew set quite a milestone there, to cover all of this will require a lot of filming :).

    Regarding your questions:

    "Mix Event Mode Dir Divider..." are available when the Menu button is pressed and then accessible via the upper Matias row of "General Purpose Keys".

    The upper info of "G1T1  Out1  Chnl.1   PANote   TA:Gate   Step14   C3   Vel:100   Len:75%   No Cat " is not really associated with the second Matias key row - it's just a general status info - where you are at and which note you are looking at. Of course, you could use the second key row to navigate, e.g. choose a different track. Then the top info "G1T1" would change.

    The secondary row generally is just an "on/off switcher". For example: if your radial second-row-selector button is set to "Track", you can use the second row of keys to simply choose one or multiple active tracks. This only needs a single keypress per track selection - in the previous SEQ v4 you had to select via group and track-within-the-group first (G1T1 -> two key press actions required).

    Another example: if the secondary Matias key row is e.g. in Mute mode, you can mute/unmute any track, independent from the "main SEQ screen" you are in. E.g. you could be in an edit screen where you can set the length (always with the OLED and the upper Matias row) and still have the mute/unmute functions available on the secondary selection row.

    So, the OLEDs are always associated with the upper encoders and the upper row of Matias switches - most of the SEQ (e.g note editing, track configuration like length etc) can be controlled from there.

    The track grouping of 4x4 comes from earlier on, MBSEQ has been available for many years! :) It's also grouped like this by design - a group of 4 tracks is called a "pattern" and you can switch through/exchange patterns and thus replace multiple melody/drum output tracks at once, e.g. if you're performing a live session and want to alter sequences, more than one.

    If you have any other usability questions or would like to see screenshots of the SEQv4+ for a certain usecase/question, please do tell, it's not a problem!

    Best regards,

  14. Hi Uli,

    how's your MIDI wiring?

    SEQ MIDI OUT1 -> Synth MIDI IN

    Synth MIDI OUT -> SEQ MIDI IN1?


    Things to check:
    * On the synth side: Forwarding "off" -> this is sometimes an option there to provide for a missing "THRU" port - then all MIDI data is forwarded from IN to OUT already on the synth side

    * On the SEQ side: check your MIDI Router screen to avoid a similar echo (form SEQ IN to OUT)

    If the loop appears only if the sequencer engine is running, you can check your MIDI CLOCK settings on the SEQ. E.g. if your Synth for whatever reasons echos the MIDI clocks, you can disable receiving MIDI CLOCK on SEQ MIDI IN1, this would also avoid the MIDI packet storm.

    Good luck and best regards,

  15. @Made In Machines thanks for your interest in the demos - for now, we can highly recommend Andrew Scheidlers great tutorials on the V4 - these are very extensive:


    The v4+ "only" differs in usage by having a secondary selection row - its mode is chosen with the circular arranged buttons around the jog wheel. So you could e.g. be in the SEQ v4+ transpose screen, while the secondary selection button row would be set to "mute" - so you can mute and transpose without changing screens.

    Of course, new tutorials would be great - but they will take time in making - i think @Menzman is preparing something here in his new video studio! :)

    Best regards!

  16.  @j4ustin and @keelhauler - congratulations are in order, well done! :cheers:

    Thanks for uploading pictures of your completed LoopAs! And very sweet QA! :)

    Working on firmware release v.207, which should be out in a week or two, if all goes according to plan - in addition to the new features from v.207pre1 (listed and linked above), it will finally support polyrhythmic sequences and about 30 more time signatures in addition to the standard 4/4 time :).

    Best regards and enjoy your new LoopAs!