Fozzy The Bear

Sorry I'm afraid not at the moment..... The project is still in progress, but I've had quite a few problems to deal with in real life. Not been able to get back onto this project fully just yet. I promise to update you guys on this soon! I'm still planning to get this finished completely before the end of the year. Or at least I hope I can. Best Regards, Julian (Fozzy The Bear)

WOW..... Just realised that it was last May, that I last updated the progress on this one. Lots of things have been happening in life as well as with synths.... First of all I've been very unwell and been in hospital twice. Which kind of completely halted the progress. But it has given me time to think about how to best achieve the results I need from this project. In synths... I've acquired a few new (well second hand ones anyway) since last May. A Novation "Supernova 2" rack, Which is possibly (IMHO) the best VA synth on the planet (except of course the Access Virus TI, which I still want)... Mind you that said, it's taken Access 10 years to get round to copying the modulation capabilities of the Supernova. I also acquired an EMU ESI4000 sampler, which is like rocket science compared to my old Casio FZ1. Very nice sounding filters on it. The other new bit of kit I acquired is a Novation KS Rack, which while it's based on the Supernova architecture is not great, and to my ears sounds a bit dull and lifeless. I've only had it two weeks and already I'm seriously thinking about selling it to fund something else instead. It's not a bad synth... Just that it's not one that suits me personally. I know a lot of people love them. On the Prophet 5 replica front, I'm now ready to push on with it, and try and get it completed before the end of the year, if I can. So sorry for the delay and the lack of updates. Best Regards, Julian (Fozzy The Bear)

You can buy the PCB's and Kits you don't need to print them. Try reading all the Midibox documentation http://www.ucapps.de/index.htm and doing a search on the forum for any answers you need. before asking questions .... That would be a good start. It's also considered to be good manners not to hijack somebody elses thread with noob questions, especially when they've been answered so many times before and could have been answered for you by a search or by doing that old fashioned reading thing!. Best Regards, Julian (Fozzy The Bear)

E-Bay from Hong Kong is the cheapest place for LCD's...... Ebay Vendor Link ... For LCD Modules. The dimensions are also shown on that auction. Best Regards, Julian (Fozzy The Bear)

Yeah!! all 64 inputs on one board wouldn't be a bad idea at all. and again people could then stuff as many chips on it as they actually need. Best Regards, Julian (Fozzy The Bear)

Do you not think that it would be a good idea to look at doing them as a DINx8 design, given the much smaller footprint?? Then people could just stuff the components they need. Meaning that you could just have 2 boards for 64 inputs?? Wouldn't this be better than ending up with 4 very small boards that have to be linked up? Best Regards, Julian (Fozzy The Bear)

I don't think it's unrealistic nILS....... Look at it this way, if he makes them DINX8 boards for example, then the cost of 2 smash DINX4 boards is over $14 USD + shipping. I'm pretty certain that a single DINX8 board for SMD's would come out at less than $14 USD per board, we are only talking about the etched board here not the components. Best Regards, Julian (Fozzy The Bear)

WOHHHHH!!!! AWESOME WOODWORK!!! I do have a CNC Router, that I built myself (see the timber on the prophet 5 project) ... To be honest you wouldn't get your woodwork any cleaner looking than you do by hand. You still have to hand finish it. The only advantage the CNC Router gives you is mm accurate repeatability. So if you were to want to build 50 cases, and have them all the same, then you could set up the machine and feed it the raw material. But the finished result isn't going to look any better than your hand work... That is beautiful. In some ways CNC would detract from that, because it's not then a totally hand made item of unique quality. Nice work, really nice work, I love it! It just doesn't get any better than that, no matter how you make it. Best Regards, Julian (Fozzy The Bear)

YES!! You got my vote for those..... As long as the board price is the same or lower than the current boards available, then I'd say go for it! SMD components are way cheaper than the through hole variety. I'd also like to see them available as a DIN X8 module AIN X8 module and Dout X8 module as this seems to me to make much more sense than just having DIN X4's etc etc like we do now. I also add my voice to the cry for all components to go SMD on them. No point in doing half a job on it. If you're going SMD then do it all. And I have to agree with nILS that you should look at 1206 or 0805 for the resistors, because it makes them easier to handle. Best Regards, Julian (Fozzy The Bear)

OK, but you may not need to re-write the app to support what you want to do.... It may actually support it natively. Not spent enough time pushing the limits of what it can handle to be 100% sure either way here. Persoannly I suspect it might well fall over trying to do it but, we really need TK to answer this one and tell us if it's actually possible to do what you want with the 64E App as it is. There's not a lot of point in re-writing it if can already cope with the demand as it stands. Best Regards, Julian (Fozzy The Bear)

It might need TK to clarify this for us..... But from what I understand of the system, On Midibox64E Pots and faders are mapped to the "encoder" entries 64-128. Which then limits the available DIN inputs. This appears to be a software limitation in 64E rather than a hardware one. It looks like it was implemented as a compatibility measure. You could however be right as I also read: "optionally up to 64 pots or up to 8 motorfaders can be connected in addition to the rotary encoders" The FAQ is also a little unclear on the limits of what can be connected and work simultaneously. TK.... If you're reading this could you clarify this for us please?? Best Regards, Julian (Fozzy The Bear)

As I understand it, you can't do that on one core.... You'd need to use two separate 8 bit cores, and link them to get that many inputs working with Midibox 64E. CORE 1 (using Midibox 64E) With 2 DINX4 Boards 22 encoders (would use up 44 Digital Inputs) Leaving 20 Digital inputs For 20 Switches CORE 2 (using Midibox 64) With 2 DINX4 Boards And 2 AINX4 Boards 64 switches (uses up the 64 Digital Inputs) (total switches now at 84) 64 pots (uses up the 64 analog inputs) The two cores linked by enabling the midibox link in the software, to the end user it would behave as a single system. I'm sure somebody else can give you more detail on that. But I recommend that you go read and digest the documentation. It will answer 99% of your questions. Best Regards, Julian (Fozzy The Bear)

The answer is yes it is possible..... BUT! USB-MIDI converters don't all work the same way and some of the cheap ones off ebay have problems with lag and loss of data with bi-directional communication. Personally I think this has a lot to do with the original Microsoft Driver that they tend to use. I know that the GM5 works because it works fine with my core. So the E-mu one should also work fine... As long as you're using the E-MU Xmidi driver for it and NOT the generic Microsoft driver. The E-MU Xmidi driver is available from: http://www.emu.com/support/files/download2.asp?Centric=1026&Legacy=0&Platform=1 E-mu say "While the Xmidi 1x1, Xmidi 1x1 Tab and Xmidi 2x2 are true plug and play and will function as a MIDI device using the included generic Microsoft MIDI drivers, installing and using the E-Mu Xmidi driver will provide improved MIDI latency, reduced MIDI jitter and multi client MIDI application operation. Tested to work in Windows XP, Windows Vista x32 & x64, Windows 7 x32 & x64" Simultaneous MIDI in and out are used by the core for a couple of things. Not least of which is to keep track of the position of rotary controls and pots and switches in the software running on the computer and keep the true (virtual) position of those updated in the midibox software... thus keeping your virtual and hardware interface controls in sync with each other. Although this is not actually essential in some applications. It really depends what you're doing with it. It's certainly essential to have fully working Bi-Directional communication for programming MIDIBOX or it'll lose some of the data. It could easily be Latency and Jitter causing the problem. Hope that helps! Best Regards, Julian (Fozzy The Bear)

I have to agree with Shuriken here.... You need to get the basic box working first. When you've done that you can look at the further development of your other ideas. This is a huge project for someone who has not built a Midibox at all, yet. It's an ambitious project. But at the moment it doesn't even have the basic control software in place. Do that first and you stand a good chance of achieving the rest of it afterwards. Best Regards, Julian (Fozzy The bear)

OK Guys, I hope the above proves useful.... Here's a list of things I think are needed to move this project forwards now. 1) A translation of Midibox 64E (in C) to run on the 32 Bit Core. 2) Some new sections of software to drive the main display. 3) Maybe some more new sections of software for Arpegiator or Phrase Seq.. although personally I think these functions are better served by SEQ V4. or other external hardware. All you need is somebody with the time and experience to do that.... No I'm not offering to do it. I'm afraid I have too much going on right now to start writing something else. Good Luck! Best Regards, Julian (Fozzy The Bear)

Ahhh!! That explains a lot them.... I think you may have got confused by some of the earlier documentation. The software for the 8 Bit Cores and 32 bit cores, Can both be written in C. Both types of core run their own version of MIOS. Which uses and interprets the compiled C language. OK :thumbsup: OUCH!!! :frantics: It's not too difficult to write a basic simple Midi Sequencer or an Arpegiator. However! a sequencer as capable and complex as MidiBoxSeq v4 is something entirely different. Picking apart the MidiBoxSeq v4 software in order to incorporate a few of its functions is probably not the easiest way to do that. In terms of programming that would actually be a bit of a nightmare. It would be much easier to just build a MidiBoxSeq v4 as a separate unit or incorporate it into the same box or to write your own basic sequence and arpegiator functions. Yes synth editing is the main object here I guess.. That's an easy one to implement... you just create a different, Midibox bank, for each synth with the correct assignments in it.The reason they're so different from each other in their CC allocations, is because they started life as individual Creamware emulations rather than an integrated system, and they obviously never put much thought into making them totally compatible. I hope that I understood what you were saying correctly and that you were not actually suggesting translating a patch from say the Pro-12 so that it works on Minimax. You'd have to view them as entirely different synthesizers. In that they do despite having similarly named controls have entirely different (virtual / physical) architecture. OUCH!! Almost vector synthesis... That's much more complex a proposition than you can imagine right now.... Let me give you an example... Lets say you have a switched function that is OFF in one patch and ON in the other... which of those settings would be correct in your merged patch and how is the core going to know which one is correct. What you're actually talking about there is entirely re-writing the synth engine.. and not using the ASX... merging patches like you suggested is not actually possible with the ASX Hardware. It's not a limitation of Midibox it's a limitation of the emulations in ASX. Actually no.... everything you suggested so far can be achieved on a Core8. Except the last one of course, but that can't be achieved on a core32 either. Everything will be faster and have less latency on a Core32, but it's not impossible on a Core8. Agreed... that is the way to go.... :D Good luck with it... If there's anything I can do to help you just yell me. Also agreed.. I like the interface on the Origin. It's very intuitive, I was using one last week. Like we both said, trying to do too much in the one interface would dilute the capability of each part. I think the one thing that HUROLURA might need to do, is to get away from this box that does, everything in one, idea. Because it could get way too complex a project to ever be finished and it probably isn't what everybody wants. Best Regards, Julian (Fozzy The Bear)

The problem I have with them is that, they don't actually have much in common with each other. They are totally separate synths, with very different workflows. Especially when you look at the FMagia or Lightwave or the Vocodizer. and If it's a generic control surface that is able to actually control the other synths then speaking in the case of the Prophet you need a lot of switches as well as knobs in order to actually program sounds on it. That is the basic workflow of more or less all hardwired (non modular) synthesizers. But there are so many variations of control and choices that can be made within each of the sections that I'm struggling to see how you can implement access to all of them for each synth and keep access to each control obvious so that you know where it is on the front panel. The only way I can see of doing it, is to incorporate a dedicated PC into the box and a TFT or LCD screen onto part of the front panel. But then you run into the brick wall that the cost is high and it defeats the point of using the ASX Card. Yes... that's exactly the problem that needs to be solved, and it's one that has defeated a lot of synth manufacturers. Agreed but it'll need to be a much more capable display than the one you have on the panel design right now. It's not just a question of Knobs... it's a question of switches as well. Most of the synths have switched functions as well as rotary or pot functions. No contest on this question.... I looked at this on the Prophet 5 project and originally intended to use rotary encoders, until I realised that they give you absolutely no visual feedback as to the position they're actually in. So the answer here is that unless the rotary control is for stepping through a menu or for stepping a digital value up and down then the controllers should be, without a doubt POT's. CONTINUED BELOW.......

Guys, what I see here is a massive change from what you originally proposed. In effect rather than creating an interface for the ASX board you're now basically proposing a generic midi synth control surface with programmable knobs. The idea in principle is a very good one. However...... First of all please bear in mind that the following is a personal opinion, and just my gut instinct as to what the fairly major pitfalls are. If somebody brought this to me as a commercial project, I'd say exactly the same thing. I can see some distinct problems with it. The front panel of the control surface that you're proposing already falls over when it comes to useability with Creamware synths in the ASB.... you're already short of controls for the Pro-12 and the MiniMax on that surface, not to mention the difficulty of translating the controls of the Prodyssey to what basically appears to be an almost Pro 5 interface (with a lot of switches missing) front panel.... This is quite often where generic synth controllers fall over, because you end up with a ton of buttons or switches that you won't need for every synth and can end up short of switches or buttons on other synths. Personally I've just never found any generic controller intuitive to use with synths. Mostly because all synths are so different from each other, and it's like trying to squeeze the functionality of 50 different devices onto one surface. As the use of each knob or switch changes entirely depending on which other piece of hardware or software it is that you're controlling. It tends to get very confusing, because you end up not remembering which knob it is that carries out which function in relation to which synth. This is exactly why, when Creamware released them as semi hardware versions, they built a specific control interface for each replica synth... It actually makes them more difficult to program if you don't have the original interface or an interface specific to whichever synth it is. You can get away with this with a MIDI Mixer type generic controller, because pretty much all mixers follow the same layout and way of doing things. But that's not the case with synths. As a suggestion, Maybe you could get around some of this by using panel overlays that show the function of each knob or switch when you have the box controlling a specific device?? But even then there's a learning and memory curve involved for each separate device. Please understand that I'm not saying this to run down your project!! Far from it... I think you do have some good ideas. But please think about the implementation of it, before you rush into it. To create and invent something useful to the world, you need to be clear that there is actually a need for it to begin with. AND need to be very clear what that need actually is. Otherwise you could end up trying to create a solution for a problem that doesn't exist to begin with. It's a trap that a lot of people inventing things fall into. The question you guys need to think about is: Does the world need a synth controler that trys to be a "jack of all trades" but in doing that ends up mastering none of those trades. On top of that, it looks to me like everything you're proposing in this (except display of envelopes, which could be written in) is already available in MidiBox 64 or 64E. Re-inventing the wheel a bit. Called the Palm Audio PPG Realizer (1986)..... the Realizer features an analog model, an FM model, wavetable synthesis, and a sampler. (starting to sound very like the ASX board and the Plugiator isn't it) They were designed to show an image of a Minimoog, or other synth on their built-in monitor. Then you could control the Minimoog knobs with the controls around the screen of the Realizer. Cost $65,000.00 in 1986. This was the last product designed by PPG before they went out of business. I'm not even sure if a working one of these ever made it out into the real world. The only pictures I've ever found of them are the publicity shots. Actually, when the Realizer was first announced (April 1985), we sat around the control room laughing at the idea of virtual synths like that. We actually thought it was an April Fool joke... It was that close to Science Fiction at the time. It's still a great idea guys..... But you'd really have to work on the implementation and figure out if it's at all what people actually want. Or what it actually is you're creating in software that we don't already have in Midibox64. Best Regards, Julian (Fozzy The Bear)

PROJECT UPDATE!! Finally got a bit more progress done on this project. The wood case is now nearly completed. I'll try and upload some pictures of that in a few days or so. In the meantime, I started work on the electronics. The attachment below is the strip-board layout for a DIN X8 Module. This puts both of the DIN X4 modules onto one board, which is much better inside the machine. It's also cheaper than using the pre made DIN X4 PCB's although it doesn't look as pretty. I will actually be using two of these... One attached to the first core and acting as the keyboard controller... 61 Note Keys Plus 3 AUX buttons used to switch Midi Channel. The second one will be attached to core 2 and handle all of the front panel buttons. I'm posting up the strip-board layout in case anybody else finds it useful. The board is 61 Holes X 35 Strips.... You could possibly shrink the size a bit further but the layout would get very cramped. Best Regards, Julian (Fozzy The Bear)

Good question... personally I think it's always beneficial learning a new skill.. But only you can answer that for yourself. It also depends on how much time you have. If you have the time to do it yourself and learn to write programs then I'd say go for it. What have you got to lose. As for getting somebody else to do it for you..... You'll mostly find on here that people will help you to understand something and do it for yourself... but they're not too keen on doing it for you. Mainly because people have enough of their own projects to be getting on with. Can't really answer the last part of your question... No experience of MAX/MSP except to say that the hardware that MAX MSP drives natively is hideously more expensive than Midibox Hardware.... To be honest you really don't need it for Midibox stuff as we already have MIOS which can do most of that anyway. If you think it would be an advantage to you for other things, and again, you have the time and desire to learn it, it's really up to you. I strongly recommend that you read the WIKI..... http://wiki.midibox.org/ Best Regards, Julian (Fozzy The Bear)

Nobody answering you.... OK I'll try answer a few of them. Yes.... "Midibox 64E" supports rotary controllers as well as the other controls. Whereas "Midibox 64" has no support for rotary controllers. Read read read.... The answers to this are in the documentation. Easy!! ..... You would however need a bank for each possible combination to achieve that on a single core. So for example: Bank 1 = Buttons in state 1, pots in state 1. Bank 2 = Buttons in state 1, pots in state 2. Bank 3 = Buttons in state 2, pots in state 2. Bank 4 = Buttons in state 2, pots in state 1. You would then need to do some logic programming to determine which bank to flip to, based on the logic latched state of the two push buttons that you want to use. So for example: each of your two selection buttons can have logic written in your program, that flip flops it between one of two states, each time it is pushed: We will call these logic states either, 1 or 2 So: If button 1 = 1 and Button 2 = 1 then call BANK 1 (which puts Buttons in state 1, pots in state 1) If button 1 = 2 and Button 2 = 1 then call BANK 4 ((which puts Buttons in state 2, pots in state 1) If button 1 = 2 and Button 2 = 2 then call BANK 3 ((which puts Buttons in state 2, pots in state 2) etc etc etc..... This is not an off the shelf solution, It requires some programming to do this.... But modifying Midibox 64E to achieve it is possible. Assuming you know at least some simple programming in C+ or Visual Basic, which has a very similar structure to the C+ that MIOS programs are written in, learning the Commands for MIOS is then fairly straightforward to achieve. The other way to do it would be to run two separate cores... in which case you could bank switch each core separately. Hope that gives you something to think about. I'm sure there are other ways to do it as well, but these will work. Best Regards, Julian (Fozzy The Bear)

Yes that's right.... as long as you remember that when you are uploading a program to the core that you will need to know the header that you chose. It's OK to use the first core with all 0's in the header, if you later want to expand the design and add another core you just make the new core end in 01 and the next one end in 02 and the next 03 etc etc..... Best Regards, Julian (Fozzy The Bear)

Yeah! and very good it is too..... He should also check out and read the WIKI WIKI LINK CLICK HERE Best Regards, Julian (Fozzy The Bear)

Midibox 64E supports rotary encoders attached to DIN modules. In answer to your earlier question, the 64E supports 32 Rotary Encoders, because each encoder uses up 2 of the inputs on the DIN Modules. So for example 2 Din-X4 Modules will support either 32 Rotary Encoders OR 64 Push Buttons or a combination of the two devices that uses up no more than the 64 available inputs of the two boards. For example you could have 16 Rotary Encoders (32 inputs) and 32 Push Buttons (32 inputs) at the same time. You can use four DIN X4 boards, and get 128 inputs, but you would need to do some software programming. Midibox 64 does not have the support for rotary encoders, but does support up to 64 Pots via AIN Modules. The number of inputs appears to be a software rather than a hardware limitation..... MIDIO128 has 128 DIN inputs but I believe that it sacrifices other available input types to achieve that. And you're making the right choice, by using the earlier core modules right now. The software support for the new 32Bit core is going to be a while coming yet. I strongly recommend that you read read and read some more... the answers to all the questions you asked are already in the documentation or the forum. Best Regards, Julian (Fozzy The Bear)