Hawkeye

Methinks, you might be able to adjust the SID frequency table (see source file: sid_frq_table.inc) and recompile - no guarantees, though :-) Many greets, Peter

Yo, more than ok. Sick of through-hole :) Thanks, man! Many greets, Peter

Very cool! :D For the parts: The display is a Newhaven NHD-3.12-25664UCB2, which is available on mouser and digikey. The illuminated tactile switches are from MEC (reichelt), but it probably makes sense to use something available on mouser/digikey, too. The encoders are alps stec 12mm encoders with switch, but it would be ok to also use any 16mm encoder with switch (that is also available from mouser/digikey). The control surface consists just of standard MIDIbox DIN -> switch/encoder, and DOUT -> LED wiring, it is all in the ucapps.de schems :-): We need a DOUTx2 module for 16 LEDs: 12 switch-LEDs and four beatstep LEDs. We need a DINx3 module for 18 input connections: 12 switches, 2x2 lines for the encoders and 2x1 lines for the encoder switches. (i know, 18 is not a good number of input lines, but the encoder switches will be used for the menu system, later on ;-)). How it's mapped does not matter, it can be reconfigured in the software, just make sure, the encoder lines are on the first DIN shift register, pins 0, 1, 2 and 3 for encoders 1+2. The display is basically connected like the small OLEDs used everywhere, but it needs a 3V3 regulator, as the onboard reg on the STM32F4 is too weak. I'll draw up something, once it is less hot here in Germany :-)) Space-wise it would be nice to build it as small as possible (the shown prototype is like 8x14cm or so), this keeps the cost and the studio footprint down. Have a great day! Peter

Thanks, Altitude! Creating a dedicated CS PCB depends a bit on demand - i'd love to see one created, but have no experience in PCB-routing and do enjoy summertime more, right now :smile:. It is a pretty small setup, it should not be too costly to create and could be used for other MIDIbox projects, as well (kind of a super-SCS). It would incorporate just a nice graphical display, 2 pushable encoders, 12 switches + 12 switch LEDs. It would be great, if the shift registers would be onboard (like on Wilba's SEQ PCB). External ports: only the display connection (16 pins) and a serial connection (10 pins) to the core. So, if anyone wants this bad, please step ahead! :-) I would then supply a template for an aluminum frontpanel for the LoopA on top :-). Many greets, Peter

Science Breakthrough! :alien: It will have to do for the first iteration. A few glitches/bugs and quite some extensions on the wishlist, but it will have to wait - celebrating the nice summer now :afro: Many greets! Peter

Thanks a lot, J and TK.! :smile: There has been a little bit of progress (already commited) - recording to incremental MIDIs in each clip slot works now, as well as parallel playback of multiple clips. Great idea with using new filenames when starting a new recording session! Unlooped playback of normal recordings seems nice and in sync, no problems with SD card speed :-) SRAM would have been my first choice, too (especially regarding timing), but after some experiments (the voxels need some RAM, too), i only managed to allocate around 800 midi events (2 events for note on/off) on each of the eight tracks, so i stopped there, basically because i wanted to record potentially really long jamming sessions, so recording to SD was a must... but that works fine (i have not tried parallel recording and playback yet). For clip loop playbacks, I still have a logic problem, that is a bit too complex right now :-) We have pre-fetched MIDI-Events from clips on SD card, that need to be fetched a bit before their "time", so the sequencer can play them just at the right moment. For the clip loops, at some point in time, we need to jump back to an earlier file position (loop start point, e.g. start of midi track), but it is difficult to determine, when that rewind (followed by a prefetch) needs to occur, for the clip to be exactly in sync with the song. Need to think more about it - any thoughts are welcome! :-). I think, some kind of a loop-hint index is necessary, but my brain is hurting ;-) Many greets and have a great day! Peter

Yes! 32 output shift registers should theoretically work, you set them in mios32_config.h, but the max ever tested/enabled were 4 MBLRE boards for MBNG, as far as i am aware. It should be possible to extend, but we are again unsure about the possible signal detoriation in the SR chain. Therefore, we don't know yet, how long the chain can actually be - the longer it is, the more problems may arise - the boards themselfes take up quite some room, and the cables will be quite long, physically. Jojjelito and myself were opting for an eight board MBLRE8x2 / 128 encoder / 2048 LED monster in the beginning, that would require all 32 output SRs. That just *might* work, if we can manage to tune the SR length to 36, as we need 4 more output registers for the 32 encoder OLEDs (the enable lines there). It might also fail epically and we would have to sell off 4 excess boards, each :-). If we will ever build it - we don't know yet, i have about half of it ready yet and it was lots of work. But the boards are there, the encoders are there, and i have another 2000 LEDs in stock ;-) Also, we are fully aware, that this is insane, but... you know, the FS1r has thousands of tunable parameters, so bigger was better in this case :-D. Anyways, you are right, with the 8x1 boards, it should be possible to drive 64 encoders with LEDrings and displays and stay within the limits of the SR chainlength. No guarantees, though :-) Many greets, Peter

Fully agreed - it would have been really nice to try to sell it in the Fleamarket section first and to offer a bit of assistance, if something goes bad... Ebay buyers may have different expectations than forum members and will likely come back here and ask for assistance at a later point in time...

Hehe, no worries, nobody is forcing anyone to do anything :-) The problem is with the output shift register ICs - we have a limited max number of serial shift register ICs - a 8x1 board would need 3 output shift registers (8x16), a 8x2 board only four (16x16) for the LED-Rings. Considering the maximum amount of output shift registers in a MIDIbox, this leads to a significantly smaller amount of encoders and LED-Rings in the case of a 8x1 setup. For the Programma, the goal was to go for the maximum amount possible, as complex synths really need lots and lots of encoder real estate :smile:. If you can live with, say, 32 encoders (maybe a bit more, if serial chain settings are tweaked), the 8x1 setup is great and will lead to even easier LED integration (probably without the ULNs). But, with a 16x16 matrix, you can always do nearly twice of that. Many greets, Peter

Thanks for your ideas and thoughts! FantomXR: regarding the picture - i am still mounting the final OLEDs, will post a video, after that is complete - for now, there is only the demo video (Alpha Juno) with the 10 OLEDs running as displays, but i've now got all missing 14 displays here and will work on it soon. I've created a new panel for the Moog LP/SP synths, that will employ the full area with all encoders and 16 label displays. Also, I and jojjelito will likely continue on the road with this hardware set, because it took some time to build it and imho the displays fit extremely well between the encoders - it "just" needs 7 enamelled copper wires to each display. Time-wise it does not need longer than soldering in the 256 LEDs into one LRE8x2 board... Therefore, it is ok for me, but i can totally understand, if it looks scary for someone building this :-). From the software support side, it would be optimal, if someone would be able to create a 8x2 board, with four oleds mounted diagonally in between, so that everyone can use the suggested Programma layout :-). I know, this is probably a dream! :smile: That's why I suggest to make the label display loader code a bit more flexible, so that other OLED configurations (and encoder boards) can be supported. On the software side, it is not easily possible to mix different display types - it also makes not soo much sense, as the 128x64px OLEDs are great resolution-wise - you can use many of them, if you need more room. Latigid on: If someone would design an encoder board with only 4x2 encoders, we will have the problem of output shift register multiplexing, for a bigger box, we would end up with just too many shift register ICs (and smaller LED matrices than 16x16). SmashTV had some thoughts on this process already, but it is a difficult and very time-intensive design. Maybe a 4x4 (horizontal/vertical) encoder/ledring configuration would be cheaper in the PCB manufacturing process? The 16x16 matrix LED multiplexing works well for me (with ULNs) and is really bright, even with green LEDs behind smoked (~50% light intensity reduction) transparent acrylics. As a conclusion, the Programma will continue on the proposed hardware basis, well knowing, that it is next to impossible to get new MBLRE8x2 boards. While we wait for someone to step forward and design a nice integrated e.g. 8x2 or 4x4 encoder + ledrings + 4 OLED board (with published Gerber-files for reproduction for later users). When that happens, I'll try to support it and will try to make at least the label display loading code working on it. Many greets and have a great sunday! Peter

Yes, everybody may sell up to 10 pieces of assembled MIDIbox hardware per year - this limit is to avoid commercial exploitation. It is a great move, because if someone wants to solder (and more importantly, stays active to support his/her work), he/she can just do it without any hassles. See Fleamarket forum section header: Here you can offer your spare parts or complete MIDIboxes to the community. Please note that it is allowed to sell up to 10 MIDIboxes per year without special permission from the license owners (see also the TAPR license). Many greets, Peter

Yo, TPDs for the win, you all need one! :-) Sorry, got carried away! Have a great weekend! Peter

Thanks! Currently working on the MBLoopa, because this fruit is lower-hanging, the Programma will probably take some more months to be complete :-). As it is just a feature enhancement of MBNG, everything is possible, Programma is just a name for a certain hardware set. For your variant, you might need to reconfigure displays/LED rings/encoders and build your own labels in Photoshop - i did so for a Moog Little Phatty a while ago, and it was a completely different synth with all that control! :-) If you want to start with a smaller box, a good setup would be to use just one MB-LRE8x2 board, or an equivalent (maybe built by FantomXR) and a few label displays. It won't have all the bling of the 64-encoder/1024 LED/24 OLED box, but it will surely be more fun than a displayless commercial controller. I will have to add a configurable bitmap display-label loader/bitmap switching support for the .ngc config files (that would reload display labels on bank switches), currently, it is just dumb/hardcoded. If TK. approves, it might find its way into MBNG itself... unfortunately, I have no experience regarding modulars/CV, you'd need to ask jojjelito - if you want to try it now, the MBNG framework already does support 32 CV channels output via Aout modules, and it can save and recall patches (but i don't know, if it would send CV/Aout updates from recalled patches already or if it only does output via MIDI)... Have a great weekend, Peter

You're welcome! The alps encoders require a bit of pin-bending, and it is some work to do, that's why I did not recommend them anymore... the Alphas won't fail you, i've got them in my MB6582 since 2010 and they are the best encoders, I've ever had in any synth. Also, the alps did not fail me in the MBSEQ, but if they are hard to get... stay with Bourns or Alpha :). If any encoder does not work right at first, experiment with the DETENTED settings in the config file, you'll get them working... Many greets and have fun! Peter

The big advantage of push-button encoders is the option to use the "push-to-accelerate" feature, which is awesome on the SEQ. So, the Bourns encoders have my vote, if there are recent positive reports about them (some time in the past, a few people reported problems, but hopefully, it was just a temporary quality issue). Many greets, Peter

* 17 pcs Alpha 16mm encoders (without push-button function) Mouser P/N 318-ENC160F-24P You could also have a look in here: Enjoy the build! Many greets, Peter

Great job, Fantom! :smile:

What do you intend to do with it? For anything to do with analog signals in the audio domain, these good old 10-50MHz scopes from ebay are sufficient. If you want to check timings on microprocessor level (e.g. debugging a display connection), you should invest in a digital scope, that has a higher bandwidth, otherwise you won't be able to see what is going on. Going for 2 channels is recommended in any case, so you can put probes on different parts of the circuit and see what is going on :). Personally, for me, I invested ~40€ a few years back and got a retro Hameg HM-203 two-channel 20 MHz tube scope :). It looks cool and already helped in a few situations. But of course, it is not modern and might fail at some point in time. Then, on the other hand, I don't need higher bandwidth yet, and the investment was rather small :-). Have a great day! Peter

<retro hack mode> (box1) DOUT -> DIN (box2) (box1) DIN <- DOUT (box2) </retro hack mode> ??? Depends on how complex the data structures are, that you need to send, but setting up s.th. with a simple pulsed clock and maybe parallel data transfers should be < 50 lines of code on both ends :smile: (i never said how long those lines are :-))

Thanks! Meanwhile, the 16-greyscale levels font renderer works (it is already commited in the repository) and can be used for "font outline" and "font overlay" effects. The loopa can now be used as a standard one-track recorder with playback with visual voxel output. This is basically just the MIDIO functionality with simplified use with four buttons (Play/Stop, Arm Record/Record, Previous Track on SD, Next Track on SD). Am now trying to play back multiple MIDI files at once, which should work, because TK. did some amazing work with prebuffered MIDI-file reads from the SD card. You can basically define how many MIDI events should be preloaded from the MIDI-file, before they are inserted into the sequencer module. As long as the SD card is fast enough, there should be no buffer underruns and all should be in sync... let's hope for the best! :smile: Last evening, the gurl stopped by and asked if i build a new retro car radio. So much for the ugly design. I hope it just needs a manufactured aluminum/plexiglass frontpanel ;-). Hehe, have a great day! Peter

Awesome! :) :laugh: Now if we could just find a PCB layout trace master, that would be willing to integrate a quad-OLED wiring with Fairlightiis MBLRE 8x2 board :ninja: Am currently wiring up the OLEDs manually and it is wire spaghetti deluxe. Of course, that adds to the coolness factor :afro: , but it is some work... Hehe, have a great day! Peter

You are positively insane, man! :phone: :phone: :phone: Have a great day! Peter

Cool! :phone: The big thanks goes to TK who made all of this possible and coded 95% of it, this is (for now) just a code remix of MIDIO and my old voxelspace demo... In the loopa, the display flyby is reverted, the notes appear in front of the screen and "fly back" as mountainline. It feels very responsive and should be an inspirational little tool (better than any windows laptop), I'll put up a video, once the font renderer works, and we see some more of the stuff, that is going on (like the current clip position) while recording :-). Have a great day! Peter

Great job, it looks awesome! Congratulations! Many greets, Peter

Hola, we recently had some very rainy days in southern Germany and MIDIbox-build-fever struck again, so I had to do something... my project build stack is very large, and even some started projects are not complete yet (MBProgramma), but this one has been on the wishlist for even longer than the Programma, so I just had to start it this year... otherwise it would probably never happen :-). I have to say, that the MIDIbox platform is phenomenal and addictive! It would be so nice to work on something of this quality on a daily job basis... results can be reached very quickly, the documentation and code base is great. Thanks a lot for everything, TK.! Let's start... Motivation * DAW hate Turning on the computer and loading a DAW as complex as Ableton or Cubase makes sure any of my already limited inspiration will be gone by the time it is able to record MIDI. I'd like to sit down and "just jam". I felt, very often, that what i played was lost in time, because, of course, the computer was off. So I wanted a simple MIDI recorder, that "just records" automatically a few seconds after turning it on, without any major interaction. If what was just played sounded nice, it would be automatically stored on SD card in compatible .MID format for later playback or even some DAW-based post-processing. If not, well, one could just jam on, or delete the track (called clip in this app). * Hardware minimalism Building the unit should be quick and cheap. There should only be a minimum number of buttons and encoders. I managed to build everything including the control surface (yes, i know, it looks cheap, but it also was cheap :-)) on one long weekend - and so can you. We just use standard hardware (STM32F4 core, one DINx4, out DOUTx4 and a nice display). Because there are few components, it is very viable to do it on vector board, no immediate need for PCBs... * Space minimalism As we all have very limited available upfront space in our studios, the unit is separated into a very small control surface (16x8x1.5cm), which is connected with a 40-PIN old-computer-IDE cable to the base unit, that contains the Core, the MIDI ports and the DIN/DOUT modules. * Bling Every MIDIbox needs a bit of bling... I always wanted to use that 256x64px OLED from Newhaven. TK. helped me in getting it connected a few years ago, but we never managed to initialise it 100% (there was some flicker). Meanwhile, Newhaven updated their Datasheets, and after further experimentation, the display now works very nicely and is flicker free. The display is still available on the market, and there even has been a reissue from Newhaven - it came to stay at least for a while, it seems. The 16 grey/blue levels are fantastic! Connection to a STM32F4 is very straightforward, you just need a 3V3 regulator, as the onboard STM32F4 regulator is too weak. Functionality (already completed) * Realtime MIDI Recording and playback (functionality cloned from the MIDIO128 MIDI recorder, thanks for that! :-)) of nearly unlimited length to compatible .MID files for later postprocessing. No quantisation or step-recording, we have the MBSEQ for that job! * Graphical Note output. For bling reasons, we currently display notes in voxel space. That means, when a note is played, a "mountain" is drawn - left side are the low keys, right side the high keys - the mountainscape is scrolled continously, so that we "paint" a mountainrange while flying over it. Beats/quarternote timing is indicated in the mountainrange, by an area of "even terrain". Higher mountains = higher key velocity/louder notes. A demo video should be up soon :-). Smooth framebuffered playback @ ~30fps, the STM32F4 is great! :smile: * Proper MIDI sync with a MBSEQ V4. This was very important, as the SEQ is the mastermind and controls all MIDI synths here. Pushing play on the SEQ, while the loopa is armed will record "in sync". The same applies for playback: when a clip is armed for playback, and the SEQ is started, it will playback in sync with the MBSEQ as a MIDI timing master. This already really works really well, and i spent the last night just smiling and jamming! :smile: * Beat LEDs are working - the leftmost is a red LED and will blink on every beat/ quarternote (like MBSEQ), there are three more green LEDs, which will flash on the 16th notes. * The illuminated clip switches are working. For later on, the illuminated switch will show, if a clip is "filled" with MIDI data (solid on), is armed for playback (blinking slowly, every quarternote) or is armed for recording (blinking quickly, every 16th note). Work in Progress/Wishlist This will likely take a a lot more weekends of programming and adding code to be complete. But then, I really love to see small steps of progress. Even now, just a few days after starting with the project, the unit is quite usable, although it just records to SD and plays back a single clip and draws some nice voxelspace mountains while doing so :-). Further items on the wishlist are (all unfinished, yet): * Support for a graphical variable-width-letter font, that supports the 16 shading levels of the OLED. This allows to use an antialiased font for a clear display and "visually round font corners". * Support for playing back up to eight pre-recorded clips in parallel (currently only one clip is supported). The idea is to load the MIDI files into memory and play them back with a mute/unmute feature like in the MBSEQ V4. * Support for synchronized muting/unmuting of clips * Support for looped clips * Support for editing clip start/endpoints, e.g. for loops or for one-shot playback (with the left and right encoders) * Support for multiple sessions (one session holds eight clips) * Support for a 2D noteroll display (toggle "Mode" button to switch between 3D voxelspace and 2D noteroll is already reserved :smile:) ... hope you like it so far, i will update this thread, when new changes are made to the software. Have a great time! Peter