Hawkeye

No problem, here: http://www.midibox.org/dokuwiki/doku.php?id=wilba_mb_6582 especially here for the baseboard: http://www.midibox.org/dokuwiki/doku.php?id=wilba_mb_6582_base_pcb_construction_guide and maybe this one for the control surface :) Have fun! Peter

No problem, i've deleted the other thread. Regarding your question, maybe it would be easiest to just start building the MB6582 baseboard (and e.g. populate it with a single core and two SIDs first) - it connects easily to the MB6582 control surface and all is well documented. As you were already thinking of going that way, i'd recommend to just do it. The MB6582 baseboard needs not be fully populated with PICs and SIDs, you can just start with a single core and a SID pair. Many greets, Peter

Andy aka latigid on has developed a new core based on the waveshare Core407V, afaik TK. has already successfully used it in his first prototype MBSEQv4+. The new core PCBs should be publicly available somewhen in in springtime 2018! Many greets, Peter

It is the bass - with the Programma (which is a MBNG and nothing else), you can control all parameters during the live performance, if you have the space and are looking for an easier to-program and more powerful variant with the same awesome analog filters, search for the SQ80! :) Thanks a lot, m00dawg, welcome back to the forums! :-) Have a great time! Many greets, Peter

Also agreed on that! Back in 2010, without thinking, i automatically put all "important" controls of my first/original SEQv4 (the narrow one below the synths) on the left hand side, to be able to play the keyboard with the right hand. Until now, I have never second-guessed that orientation and am really happy with it. Maybe this should be the recommended/"default" setup of the new MBSEQv4+ for right-handers? As Bruno, asked, i would be also interested in what left-handers think? My sister is a left-hander (but not into synths :)) and i know that during classical piano training we both received as kids, they had to emphasise training on her "weak" right hand, as this often (but not always) has to play more complex passages (in classical pieces anyways). So left-handed keyboarders may already be trained to prefer their right hand for non-bass sequences and would also prefer the menu on the left side? Just some wild guessing going on from my side... :) As far as i've understood, cases for both versions should be available at some point in time, so it is not really a "this or that" decision, everyone needs to decide on his/her own when building a new v4+. Many greets, Peter

Thanks, guys! I would not consider a reference to the new Blade Runner soundtrack an insult, thanks Bruno :)! (in fact i really liked the new blade runner film, it may be polarizing, but boy, they really managed to transport the old atmosphere and the music/soundtrack at least was not totally off :) - but this is just a personal impression)! And of course i am jealous on all the synths Hans Zimmer owns! :) Have a great week! Peter

Thank you both! I try my best to not spam the music forums here in 2018, but sometimes you just have to sit at the synths and play some notes :). Have a great weekend! Many greets, Peter

Hola, Could spare two hours for the first jam in 2018 :), this time with MBLoopA, MBProgramma and the MB-6582 :) Me had some troubles with the Programma, as it was suddenly inoperational from one day to the next, fortunately only the SD card was damaged, no file system could be recognized. I just formatted it, restored the files and all is well again - the prototype still works :). In this track, the Programma is used to control the bassline synth, the Ensoniq ESQ-M (the spiritual successor of the C64 SID, also from Bob Yannes). Some wild osc-octave switching with quite high filter resonance can be heard later on in the track :-). No MBSeq used here, only the MBLoopA - thanks to Andy, we hope for the public availability of LoopA boards and essential/hard-to-source parts somewhen in springtime! :) Thanks for watching and listening and have a great time with your synths whenever you have the chance to do so! Many greets, Peter

Personally, i see three potential arguments for a classic 7809 linear vreg, but they are highly subjective, others may have other thoughts about it! Here they are: * it is cheaper :) * the power draw of the 8580 on the 9V rail is not high, it is "only" used for the analog part of the chips, primarily op-amps, i guess. * they feed the "analog part" of the SIDs, therefore purists might want to avoid switchers there if possible, even if the recoms have a very high, probably inaudible switching frequency. Most likely you could install a 9v switching vreg without any problems. Many greets, Peter

Hi, that is quite a long build-list, enjoy! ;-) Regarding your question: it is not possible with the default MBSEQ firmware, but if you are confident with a bit of C/C++ hacking, this should be doable within the SEQ - but it would be a customized firmware effort that you have to track for every new release TK commits, so it is not really recommended. So, if you don't want to go that way, it should be possible (most likely there are also other options!) with a MBNG, the minimal version consists just of a core and a few MIDI ports for input/output, you can configure it via "text files" on the SD card, so the build effort and the costs are low. Many greets, Peter

Most likely, it is a quota/filesize problem. You should be able to reduce the JPG quality of some images, to get it well below 1MB (the last version was 400kb or so), then i have the feeling it might work again in the forums or the wiki. If you cannot reduce the filesize by reducing the image quality, you could just split it in two PDFs and upload them. PS: Nice work! Happy holidays! Many greets, Peter

Very nice! Welcome to the forums! Many greets, Peter

Hm, everything is working fine here, can you try to a) clear the password store within the browser b) clear the complete browser history/session cookies for the domain midibox.org c) change to a new browser (just to try it out if it works there)? In short: it will not work, if your browser is supplying an old/outdated password to the login dialog. Many greets, Peter

Good to see, that there is progress! :-) I can't check the whole code, but there might be out-of-bound memory accesses somewhere, that will usually result in a crash sooner or later. It might just work with an array size of 512, but would crash when using 1024, welcome to the beauty of C :-). You need to double-check all write-accesses (indices). A good strategy here is to "comment out code", and see when the problem stops. Then look at the commented out segment and subdivide it, comment out more, you should be able to find it like that. Also regarding speed, as you are only doing small assignment loops up to 1024 or 512x8 or so, this is easily fast enough to be executed on a button press, for that there is no need of a background task. You could even do this every sequencer tick or so in the main thread and it would still probably be fast enough - multithreading just adds even more difficult to detect problems, avoid it for now if you can. Many greets and good luck! Peter

Hi, in this line is the problem with the failed initialization, can you find it? :-) Regarding the identical file-sizes for two different structs: the structs look good. You could output the value of sizeof(store_t) either to your LCD or as a MIOS debug message to the MIOS terminal - i bet the value looks good and it is a problem with the file writing code. Also make sure, you've recompiled the structure definition file after changing the structure size, if the linker links to an old object file, the sizeof calculation may be wrong. Regarding background tasks - which data are you calculating, and how often do you need to recalculate it? The core is really quite fast, in the loopa context for example, i can output/calculate on something like 16kbytes in every screen refresh cycle (something like 30-50hz). I've "hooked" the screen output routine to an xtask and it works nicely without overloading the rest of the system. If you change data, that is used in other threads/tasks, you need to protect by a mutex though. It is a bit of an advanced topic, that's why i ask why you cannot calculate in the main task of the running app/sequencer. Many greets, Peter

It seems you solved it, just as Bruno recommended it, with the index loop[t] you can (and did) of course address only a single struct and can read/write that at any time, even when the app is running. A filetype generally helps you to reidentify which kind of revision a file has - as it is binary, structs may change and you may not be able to load old data in a new version, so in the loader you can compare the filetype to the expected version. That happens for all non-array datastructures like plain integers. You need to take their address with the ampersand operator (that can then by typecasted to a u8 pointer) and write FILE_WriteBuffer( (u8 *)&file_type, 4 ); //"SQ01" = 4 Positons Many greets! Peter

Try something like this: FILE_ReadBuffer((u8*)loop, 8 * sizeof(store_t)); and FILE_WriteBuffer((u8*)loop, 8 * sizeof(store_t)); the trick is to use "sizeof", that calculates the data size of the structure "store_t" in bytes. Multiplying it by 8 if you want to read/write 8 of these structures at once. Make sure, that the variable "loop" is big enough to hold the data. Good luck and many greets, Peter

Hi Phatline, i don't know if i got all questions, but here are some generic answers :) * Using structs to read in data, e.g. from SD card will speed up things massively, as every further read may block i/o. * Memory alignment should only be a problem, if you access data all the time, tens of thousands of times per second :), if you only frequently need some data, don't worry too much, these modern microcontrollers are orders of magnitude faster than old machines. Use the correct memory size for your data and you will be good. * What you need to worry about is the data size of your program, so use the smallest possible data type in arrays. In short, our core is very fast, but has only very limited ram. It can calculate like a boss, but can only store 3x more than your old C64 :) Have a good time! Many greets, Peter

Thanks, guys! Awesome repurposing of these old VFD calculators, Hal, have you documented somewhere what you did there? Very cool idea! (And sorry for being offtopic ;-)) Many greets, Peter

Hi, performing a pattern switch in phrase mode imho is just like a "mini-scene" switch in ableton, 4 tracks are replaced on the fly (i think this can be synced to the measure), when you change a pattern. Also, as you have two hands (hopefully ;-)), you can perform two pattern switches at once, so that would replace 50% of the tracks, definitely something like a scene change in ableton. Personally, I only use the mute screen and mute/unmute different tracks, 16 of them are enough for my limited music :-) - here you can definitely have synced mutes/unmutes. From an organizational view, I would regard sessions rather as full songs, you can quickly load (and start) the next session after the end of the current song via the load screen, there would be only a few seconds of silence. If you are performing a "live act" with the necessity for smoother transitions, i would rather recommend phrase-mode and switching of patterns, you can have many patterns in a session, should be good enough for a long mix! :-) Many greets, Peter

it should be possible with a relais, a transistor or an IC specialized on switching. Many greets, Peter

...checked the start info page of MBNG http://www.ucapps.de/index.html?page=mbhp_core.html and seem it support 128 rotary encoders and 2048 leds (cool...or i'm wrong?) , then 32 - 48 rotary encoders x 16 leds each = 512 - 768 ... About lcd display however seem still only 2 screens (or i'm wrong :cry: .... , again ? ) The Programma V1 prototype "uses" MBNG - and consists of 64 "pushable" encoders, 1024 LEDs and 24 OLED screens, these are even graphical OLEDs, that would allow to display nice additional informations, like envelopes, if there ever is the time to code that :), so no real limitation on screen real estate. That's why i recommended you to build a MBNG if you want a great synth controller. Or if you have the time, wait for MBProgramma V2 (that will be also and always be based on MBNG), that will have PCBs available and will be well-documented. It will just take (a lot) of time, but it is definitely on the TODO-list. Good enough for a start-point? Imho you really need to decide on what you really want to do FIRST, is it a MBSID, a MBSEQ or a MBNG? This thread here should be used primarily for Programma discussion... Many greets, Peter

And one little user-interface aspect, having a defined "start" and "end" can make things visually more intuitive, e.g. when you have a huge controller board with many LED-rings, it is easier to see, if a parameter is "close to the beginning" or the "end" of a range, if you have a "ring", that is not a full 360°. This comment does not apply, if you have a "progress-bar" ring, that "turns on" more LEDs (not just one) as the parameter value is increased.

One lesson learned over the years: never try to mix functionalities in one hardware box, if they can be separated, while the usecase might be perfect for you, it most likely won't fit for other people. What you probably want is a MBSEQ for sequencing and (later on, when the project is finished, PCBs are available and the build process is documented) a MBProgramma (or any other MBNG variant) for synth patch editing. Many greets, Peter