latigid on

This is still a bit of guesswork. Did you make a custom PCB for your panel? Or do you have separate boards for each component/panel-wired jacks? Is the DOUT shift register chain on a regular DOUTX4 board, or something different? How have you tested the setup? If you have a breadboard/stripboard prototype then let's see a photo with all of the wiring, especially the transistor pinout. Are you certain that the gates are really firing on and off? With a SEQ or another way? http://www.cgs.synth.net/modules/cgsld.html shows the B-E resistor. It provides a current path to 0V/ground so the transistor can turn off rather than leaking through the junctions. It's not 100% necessary, but something to try. Another option is to use an octal transistor array e.g. ULN2803 (inverted) or UDN2981.

Did you wire the transistor properly? The 547 and 3904 have opposite pinouts. You can also bias the transistor to get it triggering at different levels. This blind troubleshooting in an unrelated thread is a bit perplexing. Why not start a new thread and, post pictures/schem of what you're trying to achieve.

I mentioned it in the "Build Thread," but the reason is more personal/bureaucratic than anything else. Basically, for me to set this up I will need to create a legal business entity. People trying it in the past without have got into difficulty, even with bank accounts being seized and money lost from those paid and signed up. Several incidents of this nature over the years have dented the credibility of MIDIbox and partially contributed to its decline. So it's best to be honest about timeframes and capabilities, and to have the framework in place before a big commitment. Of course, it would be an option to open source the files and everyone gets their own PCBs made. But if anybody's making a bit of profit, it should be the designer who's put the time and energy into it. IMHO, there's enough out there in terms of MCU projects and PCBs for sale/download+fab that the risk of mass-produced clones is far lower than it was a few years ago. Having (somewhat) closed source and limited PCB supply probably restrains the size of the community; whether that's a good or bad thing depends on your perspective. Anyway, it'd be great to see more in the way of ongoing projects. Certainly it's in the pipeline from my side :).

Simplest way for you is to use a separate DOUT pin, which I'm sure can be assigned in the hardware config. The reason for using a transistor (or CMOS pin as I have) is to provide extra current for the LED, so it doesn't load down the gate when used in parallel.

@mxximus The project is on hold for the moment, but feel free to register your interest. For the moment, the design files are not open source, and it's a large multilayer PCB, so quite expensive in single quantity.

This should really be added to the uCapps info when TK. has a chance.

I might do a bulk order in the future, I'm in Germany and I'd consider a run of 1000 or so. But probably not until next year at the earliest. If it's more convenient for someone to organise one now, then please go for it.

Creative, I like! Next time you could sample into the MD (if you have the UW) and p-lock for more variation.

In principle it should work, here's an STM32F4 build of the latest version of MBKB v1: project.hex As discussed above, MBNG should be fine (and be easier to configure).

Seems like a German has the same issue: I don't use any LPC Cores, nor do I run Win7. But it's a constant struggle with this OS; the invisible hand of constant updates borks everything from touchpad controllers to audio playback to MIDI drivers. My non-scientific solution was a mix of disabling/removing/reinstalling drivers until I got it to stick. Sorry that I don't have more help to offer...

https://en.wikipedia.org/wiki/MIDI_beat_clock MIDI clock is made from start, stop and continue bytes, and clock of course. Different hardware interprets start/continue differently, and I think this is the issue described in the OP. The SEQ interprets a continue byte as a reset, while the MD/TB go from where they were stopped as I see it. Does that make sense or is it a different problem? Or do you mean that the start/continue behaviour is different depending whether the SEQ is master or slave, i.e. are different commands sent?

Merci, je le traitais. Je ne connais pas de CAN -- est-ce qu'il a vitesse suffisante? Pour le MB-6582 (MIOS8, 4* Core par CAN), ses signals sont transférées efficacement en parallèle.

Je crois que la limite de 32 faders motorisés est fixé par MIOS32 (ils produisent beaucoups des "données“). Pour enregistrer plus de 32, faders, vois-toi AINSER(64), mais les fonctions moteurs ne sont pas plus possibles.

J'essaie en francais :P Pour les fonctions matrices, on peut utliser simplement la MB DIO_MATRIX (16*16). Pour les faders, prends note que MIDIbox NG a une limite de 4*MB_MF = 32 faders. Bienvenue a MIDIbox, d'ici tous va lentement :)

It's a good deal and I'm sure someone will buy it!

I'm sure they'll sell, but it's good etiquette to put a price on the post(s). The reason being that it discourages "bidding" via PMs.

The idea from the start was to minimise the SMT and use commonly available parts where possible. The LEDs were different as they sit in a routed channel, but that was part of the choice for resistor networks in chip packages rather than discrete. Something like this would be a great investment: THT are a cent each in quantity, more for SMT. MELF = mostly ends up lying on the floor, so you'd likely go for one of the SOD packages. Looking at the design again, I think SMT would work on the rear side most of the time (disagree about the front side, you want that as flat as possible), but there are parts of the board where diodes bridge a layer. It's a complicated PCB and keeping one footprint simplifies the process. I don't think I'm prepared to redo the whole thing again because it's a lot of work and the risk would be on me not to propagate errors. I can't do a big order like this without paying taxes. Especially as a foreigner in DE it's not straightforward to wade through all of the bureaucracy and set up a business. I know you've just signed up, but it seems over the last year or so a lot of "puff" has gone out of the forum. It's less desirable to go through all of that without an active community presence (I realise the chicken-egg analogy of supply and demand being mutually dependent). I need to stick my finger in the wind so to speak and also check on my situation here. What I'd most like to see is a return to the motto of "Community Designed MIDI Devices" printed as part of the forum logo. @Phatline makes good use of it in his Triggermatrix. Best regards, Andy

Looks very nice indeed! Can you share more details about the PCB, the LEDs you're using and connections to the Core? Is it running on the SRIO chain or a dedicated port?

Yes, that way the encoder feels more like a pot. Did you ever use an Elektron unit?

No, push functions are great for acceleration. If you progress with your design, I wouldn't share the encoder behaviour, so separate the "SCS" functions into designated buttons or lock out encoder events when in "SCS mode." The hardware is simplified when you use J10 dedicated to an encoder and four buttons. In any case, if you build it you can see what works.

Board is 100*150mm, no problem for Eurorack. Thanks! 'ELO is pretty much ready to go, I just need to confer with Peter whether that's a good enough start for Programma or if he wants to work on the concept a bit more. If you're interested in PCBs and your own development I can send you some. The display driver is fine -- with one small bug that I mirrored the J15A connector. Not in the board file this time, but months before in the schematic... It needs a workaround by either attaching the header pins to the bottom of the PCB or twisting pairs on the ribbon cable (only the first 6 wires of J15A). Best,

Can't be done on the same port because one is serial, the other is parallel. It's obviously possible to do both (MBCV) but you'd have to look into the code and build your own application. http://www.ucapps.de/midibox_ng_manual_scs.html I haven't played around with using an SCS, but it looks like it might be possible to split the button IDs across multiple displays. Personally I'd avoid situations where encoder push functions also serve as buttons. It's too easy to accidentally turn when you meant to press and vice versa.

Thanks, I hope that it's interesting for people. You could also choose to leave out things, e.g. no displays, no touch sensors, no LEDs or even no encoders. In this case it was necessary to go to SMT to mount components on both sides. It's really not difficult as long as your solder is ~0.5mm for SOIC parts and you have flux on hand. The 8 chips are hex inverters with Schmitt trigger inputs (74HC14) and three gates are used per sensor. Square pads are resistors, rounded pads are caps, and there's two diodes in series in SOT-23. That way you can't reverse the polarity :). This is all TK.'s work here and here. Looking at the first one, maybe that's easy enough for me to hack some mods in. A couple of mistakes, but it's the easiest way to explain. I can't take credit for this, but it is a cool way of fitting displays in and have the corners "point" to the correct encoder. I mentioned in the youtube description that these knobs are not the "preferred" transparent "Waldorf" type. You'll get much more light out of them (especially the sides) using these, although the diffused effect is also nice. It's always very difficult to capture LED colours; I think the video does a pretty good job but your eyes are better live than via 1080p video :).

Any questions or comments, let me know. Best, Andy