tago

Hi all, before continuing my NG based synth controller and want to do a less complicated project to gain more expierence. I thought a SEQ V4 would be a good candidate. I already started with the layout (a mix of Wilba's and latigid's layouts) and have some questions. I'd be very happy if i could get some help here. Like latigids design i want to layout two identical pcbs (8steps/columns per pcb) for each side. Thanks in advance!

How important are dual color LEDs for the new layout (per row)? What do they indicate? I assume using them on the top row is most useful, but i'm not sure. Do you think leaving them out and using normal single color LEDs for everything is a good idea? How about inverting or fast blinking for single color LEDs? Is something like that implemented?

I assume the left one. There is no datasheet. Are they for d-shaft (flatted) 6mm? ('für Rundachse' is not very detailed :)) Edit: found it, yes d-shaft Cliff has 9mm opaque knobs (CL178861) Did someone try them?

What's your encoder knobs diameters? I can't find 6mm flatted or set screw knobs with <12mm diameter.

I've another question about horizontal spacing between columns responding 1:1 to the display. If i divide 148mm (active area)/8 is 18.5mm h-spacing. Is this correct? Nearest on veroboard would be 7*2,54mm = 17.78mm, the 12mm encoder knobs would have only 5-6mm space between them. That sounds and looks too narow to me. What h-spacing should be used?

Still would like to know how everything is labeled. Is it simply 1..16 on two top rows and bottom row + side panel like TK's graphic shows?

Should i get 3V or 5V (VDD) OLED displays? Which one is preferable? Edit: i assume 5V because the STM32 core outputs 5V. But i wonder if 3V can save some energy?

Yes that's the idea, having 2 identical frontpanel pcbs and 2 displays. I asked for an overview of the button labeling in the "new SEQ frontpanel idea" thread to get a better idea of the new layout. The middle button row seems for selections (1..16) corresponding to the 8 buttons around the jog wheel. But is this the only purpose for that row? The top row works like the old one, i assume. Rarely used functions could be reached via a shift button. But i've no idea if this is easily configurable in SEQ. @jjonas Thanks for your list of rarely used buttons. May i ask what the up/down buttons are for?

I'd like to see the final layout (graphic or excel) with every control labeled. I'm trying to understand the differences between this and the 'old' V4 layout. I'm thinking about the possiblity to leave out the jog shuttle pcb to get sort of a v4+ compact version.

@Hawkeye I currently consider sort of a V4+ without the new jog wheel pcb. (16x1 encoders, 16x3 buttons) For example, i could reduce the play/stop/pause buttons to a single play/stop toggle button and leave out rarely used buttons (according to mastomo). Do you think this could work?

Thanks TK I took a look into the files + some of the tutorial videos and understand the problem better now. Since some menu items spread over more then one step column, one small OLED per step wouldn't be ideal either. System and sequence/step data display are baked into that 80x2 layout. If each step could have its own data display (OLED, 7 Segment, LED Matrix or something like that) and the system stuff in a seperate display, that would be nice.

Thanks Peter. A pity there is no easy way doing it. I don't see much potential to gain some horizontal space with these display modules. Do you mean removing the controller pcbs from the displays? Why would it be hard to hack the firmware? Isn't there something like a display manager with some abstraction or is the display stuff hardcoded?

Hello, are the two 40x2 Displays the only reason for seperating the grid in two groups ( left/right each x8 columns)? I'd like to have 16 evenly spaced columns. Are there any display options for a single display configuration, where the display doesn't have to be aligned with the btn/enc grid? Thank you

I'm also interested in simplified/minimized designs. Has someone built such custom layouts?

Hey @latigid on looks nice in those little preview pics at mutable. Could you please upload larger versions here? Maybe i've to switch my project, which is similar to yours, to a hardware synth as my idea using a VSTi as synth engine may not possible due to incomplete MIDI implementations of various VSTi's.

Yes, please upload them here. Thank you! I've sometimes trouble seeing images uploaded as gallery image by the way. I only see the preview pic but not the large one. Maybe that issue is somehow related!?

Can't see any of the images.

Please help! Maybe there is a better fitting section in the forum for a question like this? ps What are the differences between Snapshots and Patches? I assume Patch is what i'm looking for.

I wonder how anyone manages presets between a software VSTi synth and a Midibox controller. It seems the problem is that most plugins don't have Midi out implemented, so there is no way to dump presets from the plugin to the controller. Only host automation allows for bidirectional communication and therefore parameter binding, but with host automation there are some parameters missing which are not exposed to the host by the plugin. Does that mean i have to use Midibox snapshots to load/save presets? Is the same issue true for hardware synths, for example Blofeld? How are you doing this?

Thanks for hint @novski I'd like to keep things as standard and simple as possible. I don't predict many MIDI events in parallel in normal operation. Maybe when a patch change in the plugin have to be synced back to controller? I've the feeling OSC or RTP could be a bit over top for a synth controller, but I've no idea. Firsti've to ensure that MIOS/Core32 is capable of doing all the internal parameter handling for me. Added: The plugin host has to support RTP MIDI, right? OSC is supported be some.

Another question. If a VST plugin (for example DIVA) exposes hundreds or even thousands ofMIDI CC's, would Midibox have sufficient RAM/CPU to handle that many params?

Hi, i'm trying to evaluate the best way to control VST plugins. These plugins mostly have Midi CC's implemented and it should be possible via an VST host to communicate via OSC instead of MIDI/CC. The manual states 'upcoming' for NG OSC support. http://www.ucapps.de/midibox_osc.html What is the state of NG/OSC implementation? And do you generally think it's the best way to go instead of MIDI?

With my current design i'd need 4* DINX4 and 4* DOUTX4 when using direct connections between Btns/LEDs and SRs. For potentiometers i'd have an AINSER64. According to the docs double than that should be possible, but is such a large number of SRs going to negatively affect the MIOS32/Core32 performance? Is it possible to leave some LEDs out (eg per row) in a matrix? Could you explain "multiple matrices based on smaller sections" any further? I'm really not sure if matrix wiring is going to be too tricky/messy with frontpanel perfboards in the end. I've to make the (large) frontpanel pcb out of smaller ones. I assume for matrices i'll need some busses on these perfboards. But how will they fit in a space saving manner on a 2,54mm grid? Unfortunately i couldn't find photos of similar projects on the web to see how others approach all this.

A single PCB of that dimension would be too risky for a beginner and the layout generally too specific to justify custom PCBs. I think i'll stick with perfboards for now, although i have no idea how i should wire all those stuff together.

The manual states: "LEDs can now be dimmed with 16 brightness levels over the value range.". There aren't any additional parameters mentioned. Like that it doesn't make too much sense for simple button/LED (on/off) combos where you want to set a fixed level. The map "trick" does it otherwise. I tried to measure the current with my cheap multimeter, but failed. It always displayed zero. The fuse in the MM seemed ok but fell apart after removal. So i'll have get a new fuse and try again. But since it's PWM is it actually measurable that way? Regarding flashlights, that why i'm doing all the testing. Maybe i should go with 10mA ones if 2mA is too dark and 20mA too bright.