MIDIbox SID V2 wishlist

[TK.]

I've started a wishlist for v2, not at least to concretise my thoughts on how to use the new possibilities provided by the PIC18F4620. If you have further suggestions for features, feel free to post them here. There is enough time (ca. a half year) before I will start with the implementation, enough time to change concepts or to consider things, which might be useful as well

-> http://www.ucapps.de/midibox_sid_v2_wishlist.html

Best Regards, Thorsten.

[Jaicen]

Looks like some exciting possibilities. Will this see the creation of a new front panel? It seems you won't be able to fit all the control improvements on the existing panel.

As far as further improvements go, I would like to see the addition of an LFO output (a simple pulse would be sufficient) which can drive external effects such as chorus/phaser etc. This would allow dynamic control over speed using the MBSID's own LFO's.

Additionally, i'd like to see a native extension to the MBSID Drum function which will allow pulse outputs to drive externally triggered drum machines or modules such as those i'm working on. If they could be driven from notes high in the register (ie, C8 upwards) that would be very useful.

You're doing some great work TK!

[TK.]

Will this see the creation of a new front panel? It seems you won't be able to fit all the control improvements on the existing panel.

I don't want to throw away my existing case, therefore it can be considered, that MBSID V2 will run with the same hardware. New functions will be accessible with special key combinations (e.g. selecting the first modulation matrix: press Edit and E1, the second: Edit and E2, AOUT matrix: Edit and L1, Trigger Matrix: Edit and L2). However, customizations (e.g. more buttons or knobs) will still be possible, but without much support from my side. The "Control Extension" (see below) will add some more control elements in form of a "breakout" box.

As far as further improvements go, I would like to see the addition of an LFO output (a simple pulse would be sufficient) which can drive external effects such as chorus/phaser etc. This would allow dynamic control over speed using the MBSID's own LFO's.

I just have added following to the CV Out item:

Gates should also be provided, they should be part of the trigger matrix (see the possibilities which are listed there). Polarity should be selectable, also the generation of pulses on falling and/or rising edge of the internal trigger source(s). In addition, it should be possible to control the gates from the drum sequencer.

Additionally, i'd like to see a native extension to the MBSID Drum function which will allow pulse outputs to drive externally triggered drum machines or modules such as those i'm working on. If they could be driven from notes high in the register (ie, C8 upwards) that would be very useful.

The drum sequencer will be organized in a different way in order to save memory. Each note will get a dedicated track. However, it should be possible without much effort to use some of these tracks as source for the trigger matrix

Best Regards, Thorsten.

[ganchan]

hi all! i'm on this forum from some time but i've never had the money to start a midibox project.. but beliveme, is one of my little dream.

i can't speak like a expert but just for what i know about my little synth experiences.

dear TK, do you think that is possible to make a mod matrix, like the waldorf xt one?

i don't know if is out of the possibility of your midibox chip's ram or what, so i just ask you if would be useful for play on a MIDIBOX SID. for me, on my (alone :() waldorf xt yes, it is :)

if you want to have more spec. on the matrix combination i'll give you more documents.

just this, sorry for my poor english.

regards, Giovanni

[TK.]

Hi Giovanni,

I don't know the possibilities of Waldorf XT, on the other hand I also don't want to throw away the already existing modmatrix concept of MBSID V1

But it could be helpful to get some inspirations, so just send me the documents via email

Best Regards, Thorsten.

[Nu-Audio-Science]

This may be impossible but here goes anyway

It would be cool if you could make the synth sub system a bit more modular

For instance if we wanted to swap out one of the core/SIDs for a core/FM we could

Or even a core/Speakjet if that happens :)

I'm just thinking an 8 SID is gonna be superb and i can't wait

But think of a 4 SID 1 FM 1 Speakjet as a kind of MIOS super synth

To be honest with those two both together would be a great couple of monster synths to me :)

Like i said probably pretty stupid but i'm all about saving space and cost of cases and buttons and such heheheheheh

[ganchan]

Hi Giovanni,

I don't know the possibilities of Waldorf XT, on the other hand I also don't want to throw away the already existing modmatrix concept of MBSID V1

But it could be helpful to get some inspirations, so just send me the documents via email

Best Regards, Thorsten.

Shure TK, i know that there is no reason to remake an existing synth, you are workin' on the most original synth  ;).

But.. the possibility that have this mod matrix are quite incredible.

I'll send you the doc and some other suggestion too..

Regards

[stryd_one]

Hey Giovanni... the MBSID already has a mod matrix...

[TK.]

This may be impossible but here goes anyway

It would be cool if you could make the synth sub system a bit more modular

For instance if we wanted to swap out one of the core/SIDs for a core/FM we could

Or even a core/Speakjet if that happens Smiley

I'm just thinking an 8 SID is gonna be superb and i can't wait

if you want to have a cheap synth with less features than today, a combination could be possible. But if you want a really powerful synth, not only the firmware should focus on a single soundchip, but also the user interface (-> front panel)

But think of a 4 SID 1 FM 1 Speakjet as a kind of MIOS super synth

I don't think so, it would result into a synth with a lot of compromisses, not only because of the additional code memory consumption. Ok, the PIC18F4620 provides twice the memory, but I want to fill it with new MBSID features, and not with hardware options which most people would never use

But.. the possibility that have this mod matrix are quite incredible.

I'll send you the doc and some other suggestion too..

I've read the microwave manual and can confirm, that the modulation possibilities are much more flexible.

A short summary: there are a lot of modulation sources, not only LFOs and envelopes, but also different MIDI events and especially the 4 modifiers.

The 4 modifiers allow to combine two modulation sources with a mathematical operation. E.g., "LFO1 / LFO2" or "MIDI Note * Modwheel" - and even complex operations like "LFO1 S&H LFO2" or "Modwheel filter" (applies a low-pass filter).

The modulation matrix allows 16 connections between any modulation source to any modulation target with individual depths - and there are much more targets than on MBSID (e.g. also ENV and LFO parameters, Depths of modulation assignments, etc...)

Of course, the possibilities are great, but I also see some drawbacks, and I guess that I've to think very long about a concept which matches with my own requirements.

a) Microwave provides only 16 modmatrix connections instead of 128 (MBSID V1) resp. 384 (MBSID V2) - so, some MBSID sounds won't be possible anymore

b) the usage is more complicated - creating a modmatrix routing takes more time than just enabling the "prepared" matrix connection on MBSID

c) all modulation targets require some special code, I fear that this will slow down the engine so much, that the current update frequency of 1.22kHz cannot be ensured anymore, instead I assume an update frequency of 500 Hz or slower. This will also affect the current MBSID sound

d) the RAM consumption for buffering the target values will be so high, that some other features might be cancled

e) the front panel doesn't match with the different matrix concept anymore, but using my existing front panel is one of the strongest requirements

The performance drawback for "16 modmatrix routing paths" provided by microwave instead of 384 "modmatrix nodes" provided by MBSID V2 might sound confusing, but this is related to the implementation (the modmatrix nodes are using prepared waveforms, they are just added to the destination)

But I don't want to say that I'm not impressed about the possibilities, especially the modifier concept is interesting.

Maybe MBSID V2 could provide similar possibilities by enhancing the LFOs - so that they can be alternatively used as generic modulator with two source inputs and an operator. I will think about this...

Best Regards, Thorsten.

[Nu-Audio-Science]

Aaaaah sorry TK

Not knowing enough about the compromises made it a very silly suggestion :(

[ganchan]

happy TK that xt had help you a little, this is was i hope.

so a little, not so important but cool push button of xt is this:

if you turn an encoder, lfo1 in ex., and contemporary push sync button, the display go directly to lfo1 menu. this is a little help some time, but i think not many ppl can enjoy.. or not?

i've think that there will be the possibility to choose in the main menù, if you want that lcd show the current setting of the used encoder's module (widthout pushing any button, not like xt) or just the normal way of use.

::)

[TK.]

MBSID already features this. In addition, you can jump directly into the LFO/env menu and select the appr. modulator when you push the E1/E2/L1..6 button of the modulation matrix.

Best Regards, Thorsten.

[ganchan]

:o 8) ::) ;D

sorry, i havent' find this feature reading the site.

[Syntax_Terror]

I've started a wishlist for v2, .........

Best Regards, Thorsten.

Haven't posted to the forum in quite some time (3 years ago allready!) But have visited the site often, and after reading the V2 wishlist I just had to tell you...

Thank you Thorsten!

For everything you think of, and build. And to the midibox community also, you could literally read posts for day's and find tons of usefull info! ;D

[Razmo]

Hi Thorsten!  :)

A new MCU... ok!... damn, I'll have to start over again when that's ready then  ;D ... Well... my idears are both hard/software, but I'm unsure about what hardware you will be changing?... is it only the core module or alo the SID module?

1. A HARDWARE DCA, controlled by the MB SID OS, so that we can get a WORKING envelope control of the volume of SID... the env. bug is just annoying! (controlling the output volume of SID dynamically via an envelope e.g.) this would be on the SID module of course.

2. As I see it, Velocity, Pressure and Modwheel can only be assigned to ONE destination... this is way too little flexible... more destinations please! Also other sources could be implemented like: Keytracking, Breath Controller, Foot Pedal, Assignable Control (CC16/17/18/19), and if possible, why not let the SIDs own source be there? The SID can be read also to deliver it's oscillator output if I recall right!? even fast pitch modulation using this reading on other oscillators could do some interresting FM perhaps...

3. Typically used modulation routings could be made part of the SIDs parameters like: A dedicated filter envelope, with it's own depth, velocity sensitivity etc. These routings are almost always made anyway, and would free up the current envelopes for other tasks.

4. More envelopes please! ... at least one for the filter, and one for each oscillator, and preferably more... well... maybe even a dedicated LFO/ENV for all paramters (pitch123/pwm123/cutoff). in essence making every oscillator into it's own little powerful synthesizer, only sharing the filter and amp section. the engine could still be backwards compatible anyways.

5. Portamento should be rate locked!... as it is now, the slide rate is constant, ... the other way, where the time it takes to slide from one key to another in the same time is much more versatile, and playable.

6. The arpeggiator should have a mode, where it alternates the pitch between the notes actually pressed!... as it is now, it allocates four notes and sequences between these, which makes it sound wrong when less than four keys are pressed... live-playing with the other method sound way cooler! (two keys pressed should result in alternating between these two notes at a constant rate and so on...)

7. Make Volume and Resonance part of the modulation matrix destinations as well! .. even though they are only 4bit wide, the effect is useable.

well... these are just brainstorm idears... some may be appropriate others not... more will possibly come as I mess about with the engine more  ;)

Regards, Jess D. Skov-Nielsen.

[TK.]

Hi Jess,

beside of the new chip, no additional hardware changes are planned. Just only extensions (like controlling a second MBHP_SID board from a single core).

I've read your proposals, they are good and I have to think about how to combine them with the other ideas and requirements. Once I've a clear picture, I will enhance the wishlist

To point 5: this is already possible by enabling the "E2P" sound engine option (CC#111 = 0x04), and by synchronising envelopes to the MIDI clock (CC#125 = 0x04)

The sound engine option is an immediate solution to keep the MBSID V1 engine compatible, with the overworked MBSID V2 engine(s) such special features should be considered from the beginning, and therefore it will be easier to find them

Best Regards, Thorsten.

[Razmo]

Hi again Thorsten!  :)

Well... sometimes it can be a good idear to properly search a site for info before asking questions  :-X... I've found you V2 pages, and have become quite a bit wiser since then  ;D

I think it's a GREAT idear to control two SID modules from just ONE core... but to understand you correctly, you are NOT making any hardware changes to the current core module exept from exchanging the PIC right? ... does this mean, that the existing core will be functional still? ... also the SID modules?

Actually, all I have been wanting from the SID, was to get those nostalgic sounds from it, and thus I would like to be able to use BOTH the 8580 and 6581 versions (independently), so that I can get both advantages... until now, this has only been possible if I had TWO cores and TWO SID modules... am I right in my asumptions, that with the "new" core, I can control TWO SID modules, with e.g. one 6581, and 1 8580 utilizing ONE core and TWO SID modules? that would be great since that means to only get one more SID module in my case  ;)

I was also wondering, if it's possible to have two different sound engines running for the two connected modules? ... I'm asking, since one of the idears I've been having is to actually connect one output of a MIDIBox FM to the MIDIBox SID audio input, making some really cool analog filtered FM sounds!  8) ... as I recall, the FM module has TWO routable outputs, so one could go out CLEAN, while the other is "SID FILTERED"... just a thought.

Another thing that I have tried to duplicate on a lot of synthesizers without any luck is the ability to control oscillators SEPERATLY on their own MID channel!... with this i mean that OSC1 could be controlled using MIDI channel 1, and OSC2 by channel 2 etc... The reason for this is that in many SID tunes (especially Rob Hubbard did this) you play one tune with one oscillator, while another oscillator pleys another... this is not anything special, bu when you then either syncronise og ring modulate those two oscillators, it starts to get VERY interresting! ... no synth I've come acros can do this! not even a Nord modular!  :o ... so I would urge you to take this idear into account... it can make some very unpredictable sequences (just take a listen to the ingame tune of Delta or Sanxion and you'll know what i mean)

Regards, Jess.

[TK.]

.. does this mean, that the existing core will be functional still? ... also the SID modules?

yes! A second SID module just requires an additional "chip select" connection, J14 of the core module is reserved for this.

Actually, all I have been wanting from the SID, was to get those nostalgic sounds from it, and thus I would like to be able to use BOTH the 8580 and 6581 versions (independently), so that I can get both advantages... until now, this has only been possible if I had TWO cores and TWO SID modules... am I right in my asumptions, that with the "new" core, I can control TWO SID modules, with e.g. one 6581, and 1 8580 utilizing ONE core and TWO SID modules? that would be great since that means to only get one more SID module in my case

this will also be possible, and in fact so long you can accept that both SIDs are controlled with the same parameters, you can already do this. Just connect both MBHP_SIDs in parallel. By enabling the CBM8580_FILTER_SWITCH in main.asm, you can dynamically switch between two filter scalings with a jumper (or switch)

I'm just extending this for the new filter type #2: defined min/max values. After this change, you can calibrate both SIDs, and switch between the two min/max values.

With MBSID V2, you only need to solder the CS line of the second SID to J14 of the core module in order to control the SIDs seperately

I was also wondering, if it's possible to have two different sound engines running for the two connected modules? ... I'm asking, since one of the idears I've been having is to actually connect one output of a MIDIBox FM to the MIDIBox SID audio input, making some really cool analog filtered FM sounds!  Cool ... as I recall, the FM module has TWO routable outputs, so one could go out CLEAN, while the other is "SID FILTERED"... just a thought.

MIDIbox FM provides up to 4 audio outputs.

It won't be possible to run two different sound engines, this would load the system too much and it would also make the menu handling too complicated.

My idea is to provide a second SID only as extension and stereo option. If different sound engines should be used at the same time (e.g. bassline and drum), one or more additional cores will be required.

Everything else will blow up the complexity too much

But if you mean with different sound engines, just a second modulation matrix for a lot of parameters - yes, this is planned.

Another thing that I have tried to duplicate on a lot of synthesizers without any luck is the ability to control oscillators SEPERATLY on their own MID channel!... with this i mean that OSC1 could be controlled using MIDI channel 1, and OSC2 by channel 2 etc... The reason for this is that in many SID tunes (especially Rob Hubbard did this) you play one tune with one oscillator, while another oscillator pleys another... this is not anything special, bu when you then either syncronise og ring modulate those two oscillators, it starts to get VERY interresting! ... no synth I've come acros can do this! not even a Nord modular!  Shocked ... so I would urge you to take this idear into account... it can make some very unpredictable sequences (just take a listen to the ingame tune of Delta or Sanxion and you'll know what i mean)

In MBSID V1 you can declare different keyboard split zones in order to control the oscillators independently over one MIDI channel over different keyboard ranges. It's also possible to define different channels, but this requires you to send SysEx strings for a reconfiguration (too complicated).

So, even the ring oscillator effects can already be realized (the easiest way to define the zones is using the Control Surface, or JSYnthLib)

MBSID V2 will provide a "Multi" engine for things exactly described above :)

Best Regards, Thorsten.

[Razmo]

WOW!... seems the new updates will make a lot of improvements then!... I'll be looking forward to seing this in the future no doubt!  :)

Regards, Jess.

[timofonic]

a) Microwave provides only 16 modmatrix connections instead of 128 (MBSID V1) resp. 384 (MBSID V2) - so, some MBSID sounds won't be possible anymore

b) the usage is more complicated - creating a modmatrix routing takes more time than just enabling the "prepared" matrix connection on MBSID

c) all modulation targets require some special code, I fear that this will slow down the engine so much, that the current update frequency of 1.22kHz cannot be ensured anymore, instead I assume an update frequency of 500 Hz or slower. This will also affect the current MBSID sound

d) the RAM consumption for buffering the target values will be so high, that some other features might be cancled

e) the front panel doesn't match with the different matrix concept anymore, but using my existing front panel is one of the strongest requirements

So MBSIDv2 wil be more limited in sound generations in some ways that MBSIDv1? It's because PIC chips are becoming small for the engine? It's this still a limit in the lastest MBSIDv2 concept? I'm afraid of design limitations on most circuit pieces  :-\

I don't want to sound bad, but seems the used PICs needs to be changed. I think a second version can't have that kind of limitations. It's your project and we are taking this for free. This is only a suggest and you are the expert designing this nice piece of hardware, so you know a lot more of this and why v2 is still interesting with those limitations (I'm still trying to understand how is designed this).

Do you considered to use dsPICs for the proyect? They seems very interesting in many ways and quite powerful too. Microchip's dsPIC33FJ256MC710 seems a quite powerful little beast. I don't know if they can be socket compatible, or maybe just doing some socket adapter.

Here are a few specs from the page:

Vdd Range                               +3.0 to +3.6

UART                                             2

SPIâ„¢                                               2

SRAM Bytes                             30720

Quad. Encoder Interface         No

Program (FLASH) KBytes       256

Pin Count                                 100

Output Compare/Std. PWM   8

Motor Control PWM             8

I/O Ports                                   85

Input Capture                             8

ICSPâ„¢                                           Yes

I²Câ„¢ Compatible                         2

EE Bytes                                   0

CPU Speed in MIPs               40

Codec Interface                            0

CAN                                               2

Clock Oscillator                     FRC

ADC 12-Bit                                 24

ADC 10-bit                                 24

16-Bit Timers                               9

PBFree Pb Free Available      Yes

Features

CAN peripheral is the new ECANâ„¢ - enhanced CAN

ADC is a double module providing 1 or 2 10-bit or 1 or 2 12-bit resolution converters with a total of 24 input channels.

PS.: Sorry if I'm very confused when trying to understand the stuff you writed.

[stryd_one]

timo did you search before you asked that question?  :P

[TK.]

So MBSIDv2 wil be more limited in sound generations in some ways that MBSIDv1?

no, I guess that you missunderstand my statements. The new engine will be much more powerful than the old one, but I cannot consider the whishes of everybody and I tried to express, why.

It's because PIC chips are becoming small for the engine? It's this still a limit in the lastest MBSIDv2 concept? I'm afraid of design limitations on most circuit pieces

The MIDIbox projects require always a consideration between features vs. performance vs. development effort vs. support effort.

I cannot mention it in every thread, but I've mentioned it several times in the past: the aim of the project is to allow even newbies to build an electronic device. I'm trying my best to keep it so easy than possible, so that not only a elitist circle of people with deep electronic skills and expensive equipment is able to build a MIDIbox.

When you read the troubleshooting section, you know what I mean - I'm hard at the limit where the high complexity demands for more support effort than ever planned at the beginning.

I don't want to sound bad, but seems the used PICs needs to be changed. I think a second version can't have that kind of limitations. It's your project and we are taking this for free. This is only a suggest and you are the expert designing this nice piece of hardware, so you know a lot more of this and why v2 is still interesting with those limitations (I'm still trying to understand how is designed this).

I just want to highlight: I don't see it as limitation that not all your suggestions can be realized. There are already a lot of new features which will be very nice and useful, and I guess that the majority of people will be happy to use them. If it would be important to get features of professional synths as a "must have", I would skip my plans and do something else

Do you considered to use dsPICs for the proyect? They seems very interesting in many ways and quite powerful too. Microchip's dsPIC33FJ256MC710 seems a quite powerful little beast. I don't know if they can be socket compatible, or maybe just doing some socket adapter.

This is a future product, from my experience it takes 1-2 years until you can dare to start a project with a high lifetime, in the hope that the chip won't be cancled in the meantime.

This controller comes in a 100pin package, I guess that only 5% of the community is able to handle this. Another problem is the availability: you cannot buy the chip at common mailorder companies, you have to contact a distributor, and they expect an order of 1k or more as minimum limit.

And even if it would be available in small quantities, the price would be propably so high, that newbies would get really sad if they damage one device during soldering with a non-adequate iron. The success guarantee is much lower.

Sorry if I'm very confused when trying to understand the stuff you writed.

I think the biggest problem is, that embedded programming is splitted into different worlds, therefore it might be hard to understand, why certain things are not possible with different platforms.

There is the hobbyist world where people are working with established devices, which are mostly in DIP packages, therefore easy to handle and easy to replace.

Programming these SoC is easy to learn, there is a lot of free literature available in the internet which helps for the first steps, and programms can be developed with free toolsuites.

Then there is the professional world where the device package doesn't matter, they are able to handle with 4 layer PCBs, they buy thousand of pieces and distributors are their friends. They pay some thousand of dollars for programming tools and analysis equipment, and they don't rely on reproducability - instead, they are very happy that not everybody is able to clone their hardware.

Are my statements more clear now?

Best Regards, Thorsten.

[timofonic]

Are my statements more clear now?

Yes, thanks A LOT  ;)

[Razmo]

Right on the spot with that answer there TK!  :)

Maybe this is also why my idears seem to get "through you needlehead" many times... I'm a coder myself, and have fiddled a bit with electronics, so I'm mostly aware of what is reasonably implementable, and what is way over the edge  ;D

It's funny... Some things that unskilled people would find to maybe be hard to implement, or time consuming can easily be a piece of cake done in a split second, while other stuff that seem elementary is a pain in the butt to implement, if not impossibe...

So a good idear for the "non-initiated" would be to just brainstorm their idears, bare none... then the technically inclined people can look at the possibilities, and maybe some obscure idears are easy to implement, and may break way for new features, maybe never seen before... in this case, I for an example are kind of "limited" in the way that, I'm thinking idears within boundaries of hardware and code efficiency.

so just keep them idears comming... TK will sort out what's feasible and what's not  8)

Regards, Jess.

[Razmo]

Hey TK!

I'm not sure if this is possible with the V1 engine already, but one thing I'd really like to see in V2 (if not already there) is the ability to have the MBSID engine work with SysX... I'm thinking about having two simple features:

1. Program Dump Request

2. Program dump

I know that you do not pay for a specific MIDI manufacturer code (you use the broadcast all value right?), but I'd really like to do an implementation of the MB SID for SoundDiver, and if there is no dump/request macros, then it's not possible to do it. The dump/request should in this case work on both the edit buffer and the bankstick memory of course. I don't see any problems in just continue using the broadcast value, since It's probably not many devices one person has, that use this... you could just put in a pruduct-byte for your own devices so that at least your own devices can be handled without conflicting...

what do you say? is this feasible?  :)

Regards, Jess.