Jump to content

Hawkeye

Administrators
  • Posts

    3,630
  • Joined

  • Last visited

  • Days Won

    36

Everything posted by Hawkeye

  1. 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
  2. @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
  3. 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
  4. @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, Peter
  5. @j4ustin no problem - and good that you found it! Cheers! Best regards, Peter
  6. @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
  7. @j4ustin thanks for the report! I'll look into it and report back to you, just working on the software anyways. Best regards! Peter
  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, Peter
  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, Peter
  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, Peter
  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! Peter
  12. @ear ear - very nice! Cheers to lucky number 33! :) Best regards, Peter
  13. @srmaietta could you check that you soldered in the correct resistor network type? There is one in the BOM that looks similar but is different. Best regards, Peter
  14. @audiomobster no problem at all! Cheers! Best regards, Peter
  15. Very cool session, nice 4/4 beat and sky/blood moon pictures! Hope to be able to sit at the synths anytime soon again, that's what its about! :) Best regards! Peter
  16. And a very nice review of the LoopA on german amazona.de: https://www.amazona.de/test-midiphy-loopa-opensource-midi-looper/ Thanks a lot for your work on this, @momelq! Best regards, Peter
  17. @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, Peter
  18. @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, Peter
  19. 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, Peter
  20. @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: http://www.ucapps.de/midibox_seq_manual_tut.html 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! Peter
  21. @j4ustin and @keelhauler - congratulations are in order, well done! 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! Peter
  22. @j4ustin if some of the switches on the encoders and on the Matias pins work, it would be interesting to know which ones don't work, this will help localize the associated problematic input shift register (or associated resistor network) on the Plate PCB, which could then be checked for unwanted solder bridges between IC pins or missing contacts from the IC pins to the PCB. As your OLED works now, every encoder switch press or "simulated" Matias switch press with a jumper wire should output which button # was triggered. If all of your button presses are working, but only sometimes, it could also be a connectivity problem of the headers - you could use a DMM to check for proper uninterrupted top/bottom header connectivity, @latigid on should be able to tell you which pins you could best check to test the way back e.g. from the first 74HC165 in the chain to the Waveshare board. Best regards and good luck! Peter
  23. @Tron77 - it might work if you're willing to sacrifice the old mixer function and would not like to run audio data through it in parallel :). Then you could separate every analog pot or fader/slider from its old PCB (i.e. cut the traces with a dremel -> this will actually destroy the old mixer function) and run wires to the DB25 connector as suggested. You're then reducing the unit just to its pots and sliders, that are externally accessible. There's one big "but": for audio applications (most likely in a mixer), there are often log/audio tapers/pots in use - but in a MIDIbox AIN environment, i think you would prefer linear pots for best resolution. Best regards and have fun! Peter
  24. @j4ustin good progress! Just wanted to recommend to use a scope (or even a DMM) to see if there is proper digital data arriving at every OLED pin 4, 7, 8, 16 and 17. If you've got the display and the LEDs sorted, you're mostly there :) Cheers! Best regards, Peter
  25. @Enginerd_0x12F looks great - well done! Congratulations to #32 or #0x20 if you prefer hex :) Also thanks for the great feedback, this surely is helpful for future builders! Best regards, Peter
×
×
  • Create New...