• Content count

  • Joined

  • Last visited

Everything posted by Hawkeye

  1. IMG_0014.jpg

    Nice job! That is a heck of a modiphyed v4+! :)
  2. Troubleshooting midiphy SEQ v4+

    @SimonSays fantastic, well done & congratulations! Many greets, Peter
  3. Troubleshooting midiphy SEQ v4+

    @SimonSays can you measure the connectivity of the PWR 5V and GND pins of the waveshare board to the wCore board (the two bottom-right pins in Andy's picture above)? If you have inserted and removed the waveshare board from the wCore PCB a lot of times, there might be bad conductivity between gold pinheaders and the header sockets on the wCore, if some headers are bent to the side (this "pinbending" can happen after forceful "uneven" removal of the waveshare board, when you lift one side quicker than the other). If you measure "fluctuating connectivity" (i.e. the continuity beeper beeps when you push down on the USB socket, and does not otherwise), you could just solder top to bottom bodge wires to connect the pins respectively. I've seen something like that happen once, when the gold pin headers of the waveshare board were bent a little bit after too many removals/reattachments of the waveshare board. It also requires quite some force to push it fully in, please measure if the standing height of the wCore/waveshare board assembly is just below 20mm (e.g. by using the provided four 20mm hexspacers), so it sits flat on your table, then it is ok. Many greets and good luck! Peter
  4. Troubleshooting midiphy SEQ v4+

    @SimonSays indeed, that should not happen! But: could you check the settings of the switches on the waveshare board? The power switch should be set to "5V in" - if it is wrong (e.g. accidentally changed it during the measurements), that could explain, why the core is unresponsive! https://www.youtube.com/watch?v=QaN26uzUA1A&t=3362s Many greets, Peter
  5. midiphy SEQ v4+

    @secrethero303 correct, the easiest way to go for "red/cyan" is to connect a single resistor from A to 1 (red) and single resistor from B to both 2 and 3 (blue+green mix). (Note: this shortcut driving 3 "logical" LEDs with only 2 resistors only works, because green and blue have very similar diode forward voltages, so current flows through both, if there was a bigger difference, most current would flow through one of the LEDs not resulting in a color mix) So, for better blue/green hue control, it might be better if you use two individual resistors going from B to 2 and from B to 3. Also, within limits, you can experiment with resistor values other than 47R to achieve a better color mix. While the resulting peak current (only during the duty cycle, average current is much lower) is officially out of "superflux specs" (and we don't support it), you might go down to 22R resistors as a minimal testing value, like this you could find an improved color mix, for example (untested!): A <- 47 R -> 1 (normal red brightness) B <- 22R -> 2 (increased green brightness) B <- 56R -> 3 (lowered blue brightness) -> resulting in cyan with a hue shift towards green Modern LeMEC boards have two holes for individual resistors at insertion point B, but you can also solder a "fork" at a single "B" insertion point, if there is only one - that should be easy. In my personal opinion, the superflux LEDs can withstand 22Rs, as they are operated only in a 1/8 duty cycle, BUT - this is out of specs and we do not encourage lower resistors than 47R from our side - while it worked for me, your mileage may vary and you might burn them up for good. If that happens, you know where to find replacements! :) As Andy knows, i had some great fun abusing a few of mine while looking for new color combinations! ;-) Many greets and have fun! Peter
  6. Troubleshooting midiphy SEQ v4+

    @SimonSays R33D should be ok - please also check connectivity of all datalines - from the problematic J15 port to the waveshare board (through the headers) - some years ago, i had a display with similar garbage and one data line was disconnected. You might also want to reflow the pins of the waveshare headers (on the wCore PCB) before measurements, just to try that out before you measure a lot of pins. If it still does not work after reflowing, measurement from J15 to the waveshare core MCU and then to the STM32F4 IC pins are the only way to check for continuity (quite some work!). Also check for "neighboring" unwanted shorts, as those could well cause the problem, too. I'd recommend to reflow every pin first, especially as reflowing on R33D seems to have helped! Many greets, Peter
  7. Questions about using STM32F4 for v1.4

    Should work! MIDIbox FM 1.4 supports the PIC18F4685. Many greets and have fun! Peter  
  8. Troubleshooting midiphy SEQ v4+

    @SimonSays wild guess, but maybe bridged "E" lines? E.g. on the waveshare board headers? Could you upload hi-res photos of the front and backside of your wCore PCB? Have you pushed in the waveshare board all the way? The wCore with installed waveshare board must be able to stand on 20mm hex standoffs, if the assembly is higher, the waveshare board is not pushed in fully. Many greets, Peter
  9. DSA clears: spider-approved!

    Oh dear, what a beast! ;-)
  10. Questions about using STM32F4 for v1.4

    Hi Theo, The classic MIDIbox FM 1.x is only available for the older 8bit core and written in pure PIC assembly and thus not super easily portable to the new STM32F4s. @Sauraen did a great job of porting, but his version is the only one known to work on modern cores. In short: you need an old core, sorry! :) Many greets, Peter
  11. Great job! It is also always nice to see MIDIboxes during public gigs! Many greets, Peter
  12. Elrom Teaser :)

    From the album Hawkeyes MB stuff

    Andy's newest - just a proof of concept at the moment - but with such a board, we hope to be able to realize a standardized MBNG user interface (aka ProgrammA) at some point in time.  
  13. Multiple projects side by side

    @tago it depends on your preferred workflow, personally i would not recommend to move anything at all outside of git, as you will lose the benefits of having an integrated code version control system, i.e. you could look at any time what you have modified locally and you can perform local commits that are not pushed back to the server while you work on your personal projects. I'd see two options: a) you could just work within your fully cloned repository tree b) i have not done it, but it might be possible to clone the main tree (library) somewhere, point your environment variables to it, so the build process works and clone the respective app subdirectories somewhere else (if this works, i think i read about "sparse checkouts" somewhere). This would allow you to work more like you describe on an individual app/project level within a separate directory structure but with full git benefits, if you prefer that. If this does not work, you could just create logical filesystem links, if you are working in a unix environment? With both variants you can perform local commits, which is useful for development. If you work from multiple local machines like a laptop and a desktop you could also setup a server system like "gitea" and enable pushing to a central server by adding a new origin - that works nicely and you would then have a local tool like "github" at home, including browser based diffs and all the bells and whistles :). Many greets and have fun! Peter
  14. Multiple projects side by side

    @tago trying to free up time for TK a bit here, if what i am saying is wrong, he will surely correct me: With libraries, the intention is to have more or less "stable" interfaces, that multiple apps can rely on. Defining the interface at first is why it is so difficult to create them :). You would need to define a  "minimal" (non over-engineered) interface at first and try to only extend it over time. If you need to change a core api function call signature, all dependencies have to be updated, that's why this should be avoided and i think this is excatly what Thorsten does. So, from an "app implementors viewpoint", you'd only need to check out everything once, and work on the "app level", use the MIOS library as far as possible. If the library does not provide for what is needed, you can extend it internally within your app. If that extension results in a function that you think will be useful for other users, you could extend the library itself and create a pull request for Thorsten to evaluate your addition to his code. The idea is always to avoid overengineering, an API that is too vast is often distracting, complex to understand and will make development harder. Hopefully this was correct and helpful! Best regards, Peter
  15. Hi, It has been a while - we have moved and i had to do a quick new studio wiring test yesterday night - using some original MB6582 "acid" basslines created by TK.! Many, many thanks for them! :) This was done in only about two hours and is not really a full track (thus the new v4+ was unused). In this video, most sounds are created by DIY devices: * MB6582 for a pair of 8580 SIDs in stereo bassline mode * Mutable Instruments Anushri for the lead * LoopA prototype for simple sequencing * DIY polivoks stereo VCF to filter the drums Thanks for watching and listening and enjoy the weekend! Peter  
  16. Elrom Teaser :)

    @FantomXR we love backlit matias switches! :)
  17. Cool review and great gear for portability! Many greets! Peter
  18. Thanks, guys! It was a rather cheesy and super-unexcercised take, just had two hours to do it, due to lots of work. So please accept my apologies, the next song should be better hopefully properly using the v4+ or at least more patterns of the LoopA. From the "restricted-time" point of view, producing something, just anything with hardware that allows to go the quick way is really fulfilling, because if you have to take the "automation" route in software, it might take so long, that you might not be able to get anything out at all! :) Many greets and enjoy the sunday evening! Peter
  19. This thread by TK. describes the requirements, both of his postings here should answer your questions: In short, yes, you'd need to get approval from him to sell PCBs based on his designs. Basically, a lot in the MIDIbox community depends on trust, that is usually established over many years. To do that, it makes sense to build and document personal projects and see how community members respond to them - that also helps to determine, if there is demand for the boards you are planning. Best regards, Peter
  20. You might be able to source common DIN/DOUT PCBs from Mike's Midishop in Germany - Andy's encoder/oled/ledring/matias switch boards currently are "work-in-progress" with no definite timeline for launch - we have to see to some other projects and get them up and running first - the displays are custom 128x32px OLEDs. Many greets, Peter
  21. midiphy SEQ v4+

    @SimonSays Welcome on board! :) Yes, many right-handed people prefer LH JOG cases, but there is no clear "right" or "wrong", it absolutely boils down to your personal preferences, in my opinion. For example, i have the v4+ directly above my keyboard, am right handed and currently use a RH JOG v4+, as during jams, i mostly use the mute screen and need quick access from the keyboard to the left side of the SEQ with my left hand to reach the primary matias switches. So, to decide, you should consider the placement of your sequencer relative to your master keyboard and think about which hand you will primarily use on the sequencer and which functions you need a lot. If you use the transport section (stop/start/play/record/live) and also the "menu dial" to switch the secondary matias functions a lot (e.g. switch between mute/tracks/layers modes) and want to use your left hand for that, going for a LH JOG variant is probably a good idea! Have a happy weekend and enjoy! Many greets, Peter
  22. Welcome to MIDIbox, @weasel! We also felt a dire need for a MBLRE replacement and while it maybe not matches your requirements, there is a similar board in the works, created by Andy: It contains LED rings, pushable encoders (for parameter input accelleration), integrated OLEDs for encoder labels (one display per encoder), a row for superflux-backlit high-quality Matias switches and could be a building block of a future unified MBNG interface - we took some efforts going that way earlier on, but there were never PCBs available. If you look up the MBProgrammA, you will find a 64-encoder - 2048 LED variant with OLED as labels @jojjelito and myself had been working on for quite some time, there should be even a video demo of it being used with an old Alpha Juno around :). Regarding eurozone availability: you could take a look at https://midiphy.com as a MIDIbox reseller based in Germany, there should be already good euro availability for standard PCBs (cores and such). Have a great weekend! Many greets, Peter  
  23. Troubleshooting midiphy SEQ v4+

    @pat_00 could you try to reupload these pictures? The forum disallows attachments larger than a certain size (i think it is 1MB?), that's probably why the images come up as broken right now -  so you might either need to reduce the JPG quality (not necessarily the resolution) in your image editor before reuploading here or you could upload them as they were on another service (e.g. imgur, dropbox, ...) Thanks and many greets! Peter
  24. midiphy SEQ v4+

    @gotkovsky fantastic job, extremely well done, if it was one of your first DIY projects! Congratulations on your new sequencer and enjoy the upcoming weekend! :) Many greets, Peter
  25. Troubleshooting midiphy SEQ v4+

    @gotkovsky  Yes, you can run it from a good 5V/1A USB supply. I have a USB Power meter (just as @Smithy posted), and the v4+ current use hovers around 0.5-0.6A during normal use. On a sidenote, make sure you have a good power supply, if you experience reboots or dropouts, exchange it for another one - i tried to attach one SEQ v4+ and two LoopAs (all have about the same current draw) to a nominally 5V/3A rated PSU on a powered USB hub and experienced reboots - using the power meter i measured it all up and and the 5V rail dropped to 4.5V :) - another lesson learned, do not assume the PSU power capabilities label on the backside is correct - my cheap PSU could not even reliably supply 1.5A as indicated by the power meter :). Many greets, Peter