Hawkeye
-
Posts
3,630 -
Joined
-
Last visited
-
Days Won
36
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by Hawkeye
-
-
@Synthfox currently ARM is automatically enabled after booting the LoopA - but this can be added as a configuration option for the next release, should be no problem, i've added it to the ToDo-List.
Best regards,
Peter -
It has been nearly two years already since the SEQ v4+ became available: to celebrate (and to integrate the newest L4 keycaps, the newly developed light|shields and the rack mount kit), here's the new 2020 facelift version: :-)
Enjoy and have a nice weekend!
Peter -
@Smithy Kapton tape should also work great! The encoders are slightly "greasy/oily" - that's how ALPS delivers them - if you have problems that tape does not stick properly to the flat part of the encoder shaft, you could try to clean the flat part of the d-shaft with a wipe first, then attach a tiny bit of tape there - it should usually stick long enough just to push the knob on - and then it's secure! :)
Many greets,
Peter -
Hi,
hm, i've not worked with Wilbas CS PCB for a while :), but could you check if you would not need to connect it to J8/J9 instead of J10a?Many greets,
Peter -
LoopA v2.07 has been released with these new features:
* CC Recording, transformation and generation
* Selective track progression (vs full scene progresion)
* Support for 30 different time signatures
* Polymetric and polyrhythmic sequence support
* Classic step recording mode
* Note velocity dampening effect (also as a footswitch action)Download here:
https://www.midiphy.com/en/loopa-v2/Massive thanks to all beta testers, who helped with this one! :)
We've also created a demo video of the essential features of the LoopA - and how these could be used in your creative workflow - this has been requested a few times, so here you go:
@silverlight2004: that's fantastic to hear, hope you'll enjoy it! :)
Best regards,
Peter -
@d0pefish, that's a great job! Looks really perfectly built and i love the golden color scheme and the custom backlight PCB solution!
Very well done!
Many greets,
Peter -
24 minutes ago, Elektruck said:
Can I have the stl files so I can print these myself?
Hi Roel,
they should be available in the shop soon :).
Printing these requires a very precise dual extruder 3d printer - note, that these shields go fully around all protrusions of the Matias switches, while being slim enough at the top to allow the key to travel "below them".
Due to the amount of effort involved developing them and capital bound on the printer, we were not planning on releasing the files, capitalism at its worst! :-).
Still, the individual sales price really won't be high, it will be around 50 cents a piece or 7,50€ for a LoopA conversion.
The light|shields will also be available in a different variant, with a highly flexible material offering the same level of light isolation, that allows converting desoldered Matias keys without removing the L4 keycaps (which might break them, if one is not careful).
Many greets!
Peter -
Great work, looks very good! Cheers to official SEQ v4+ number #35! Enjoy!
Best regards!
Peter -
@unnu_ if we can't convince you to get a new SEQ v4+ :), maybe you'd be interested in my second SEQ v4? It may need a bit of TLC, as far as i know, i.e. two buttons are not working properly, as i glued the switchcaps on for stability and might have gotten a bit of glue into two switches, disabling them, but i should have switch spares, which i would add. It comes in a very flat form factor with two yellow OLEDs and in a self-designed case, with a 16x8 duo color TPD section, but now without batteries. I think it can be properly USB powered.
If you are looking for an assembled Wilba control surface PCB and a core and maybe a few spares like a TPD module, it might be an option? I'd sell it for purchase parts costs (300€? Original costs were, i think 120€ acrylic (from Formulor) + case , 60€ OLEDs, 40€ Core, 70€ Control Surface PCB + Parts, 20€ TPD PCB + parts) + worldwide shipping (for rates, see midiphy.com). I should have another MIDI I/O extender PCB from SmashTV, i'd throw that in too, then you could have 4 MIDI INs and 4 MIDI OUTs, but would slightly need to mod the case (i.e. add them on the left side) for it.
If you don't want it, no problem! I would offer it in the marketplace at some point in time :). It's sad, if it just sits around and does not get used :).
Many greets,
Peter -
@silverlight2004 Thanks for your kind words! I've added your feature requests to the code roadmap - we hope to bring out v2.07 soon! With the new CC functions being relatively complex, there has been a constant feedback flow from the early beta testers (thank you, you know who you are!), resulting in a few more release candidates than planned for, but all is good - that version should really be final soon with just some minor things to add before publishing.
Afterwards, we'll focus on the MatriX/BLM launch, but after that, there should be time for a next round of LoopA development. As we had one more request for at least Aftertouch/Pitchbend and Program Change requests (at sequencer start), there should be a high likelihood at least these features will be implemented medium term. And i like the "one-shot-clip-launch" idea, too - it would basically result in an auto-muted track after that clip has been played back once. The major problem is not the code, but how to find space in logical locations in the UI for those functions, as most pages are already full :). Would you think it would be ok to fire "one-shots" with a key combination like pressed SELECT encoder while unmuting a clip? Or maybe with a pressed "one-shot" footswitch command, while clips are unmuted? Because i currently don't know, if we have the configuration space in the clip screen to set this variable permanently for it. Will think about it! Best regards to Bali! :)
@Smithy: cheers, well done! Also very cool, that you'll upgrade to the metal case version LoopA! :)
Many greets!
Peter -
Looks very cool as timelapse/stop motion video - well done!
Many greets!
Peter -
@Phatline good job! It's always nice to see how a LoopA is created! :)
Many greets,
Peter -
@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!
(If it works now, no need to destroy a perfectly good cable, the poor thing! :))
Many greets,
Peter -
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,
Peter -
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!
Peter -
@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!
Peter -
Thanks for the report, Mike! Very good yours is up and running now, 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:
https://www.midiphy.com/en/shop-details/0/68
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!
Peter -
@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_endThis 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_endThis 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,
Peter -
@j4ustin no problem - and good that you found it! Cheers!
Best regards,
Peter -
@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,
Peter -
@j4ustin thanks for the report! I'll look into it and report back to you, just working on the software anyways.
Best regards!
Peter -
@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,
Peter -
@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,
Peter -
@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,
Peter
blm 16x16+x Costs - Calculation
in MIDIbox BLM
Posted
Yes, all PCBs are final, filming of the tutorial video is starting and we are waiting for a final case from Adrian for validation! :)
If there are no delays, we hope to be able to have it in shop for the christmas season :)
Many greets,
Peter