"Step C" CS Design for MBFM with Base PCB

[Psykhaze]

As i wrote in another thread, i think i will stick to kiCAD for Schematics / Designs. Really like it. Good soft to share work . Having some tuts right now.
My only worry about this soft is the output files for PCB-making companies , as well as .brd files are the standard.
But i Think if you use it there is a solution =)

Edit : Latigid told me about gerber files so I definately go with KICAD

I found some stuff about the wavetable in the MIOS8 code of MBFM.Still studying. See that is not totally useless :D

If anybody could tell me about the right quick instruction set for PIC 18F4685 i would really love it.
I love assembly .  And hates the logic who says "hey, we have much power, so we can code unoptimized way with high level language because we don't care,we have power"
Didn't told that any of you is thinking this way, but i often meet programmers who does.
May sound weird , i know , but i want to stick to a CORE8 version. Low level code allows to understand things deeply. And I have much spare time right now,

Be sure i'll deal with CORE32 too. And i think after studying MIOS8 dealing with MIOS32/CORE32 will be easy as pie.

From what you're saying the waveforms for LFO are 1 / 2 / 3 / 5 / 6 ? Same for drums?

Thanks,
Regards,
JK

Edited April 27, 2016 by Psykhaze

[Sauraen]

I don't understand your confusion about the waveforms. Each operator has access to the 8 waveforms shown above. The drum mode is simply the last few operators with slight differences in their connections--the waveforms those operators use are the same 8 ones above. The LFOs have nothing to do with this; they each can only produce a sine wave (picture 1 above), and the only parameter they have is a single 1-bit depth parameter. I would really recommend you learn more about the OPL3. (Did you know that three voices of the OPL3 are completely ignored in MIDIbox FM V1.4?)

[Psykhaze]

HI Sauraen,
Thanks for helping me =) My confusion was coming from http://ucapps.de/midibox_fm.html 
as it tells the LFO has 5 waveforms , and does not says about the drums. You answered me .

I will give a review again to YMF262 Datasheet to understand things more deeply, but the link are sometimes hard to make between hardware and software features (>more features added with soft).
The question goal was about being correct on the control surface design > (correct number of LEDs,encoders etc...)

Did not knew that issue about MBFM v1.4 :( .
I started MBFMX2 Design from TK Ctrlr virtual interface meant to drive one OPL3 . A core can drive an OPL3 and good features are coded.
As my Control surface is designed to drive one OPL3 at once, i added a switch that would allow to choose between OPL3-1 or OPL3-2 parameters.

So to me the big programming deal was about 2 things:
- Code the Control surface UI in PIC/MIOS8 code : Control surface Inputs/Outputs : LED + Button matrixes / LCD Menus .
- Give acces to the UI to the 2 cores chained, each one driving an OPL3.UI code should stick on master core

Do not trying to create new synthesis features or whatelse , my start point was the Control Surface Design =).
I am still not thinking that wouldn't be such a giant deal . I may be wrong . 

Anyway, thanks again for all your help
Regards,
JK

[Sauraen]

Now I understand. The LFOs you're talking about are software LFOs implemented in the core. I was talking about the two hardware LFOs in the OPL3 (also called Vibrato and Tremolo).

I might suggest, since what you want to build is mostly two MIDIbox FM V1.4s connected together, is that you use the existing Core and OPL3 modules, and only design your front panel at first. Once you have the software working for connecting the cores, design your base PCB.

[Psykhaze]

Hi all !
After making my mind agin and again , and as well as i have much work to do, decided to forget about even using a CORE8 in the MBFMX2 Design. Lesser Work is better on great projects =)
When i began my Brainstorming, thought MBFM code was only ported to CORE8. So i started my Control Surface design upon TK Ctrlr interface (to have most params on view ) designed to drive one OPL3 with a CORE8.
And thougth that i wouldn't have to deal with any synthesis features code , just would have to make the link between the UI (matrix) and all existing features . Then link cores and access params with offset shifting.

But all of you are right. That's kind dead-in-the-egg project . Nobody or not much people will be able to help me when riding the code , i will probably may have big problems and will finish to give up.
And that's really more easy to code in C than in assembly, even if i love assembly. Shorter dev times etc...And will be able to design even more features with Core32 .

Have bought some protoboards, and already have a bunch of Rotary Encoders/LEDs/Swithes/Diodes. This will make CS hardware/software dev easier.

Made some corrections about the CS design . I let you see . Any advice welcome.
Best regards,
JK

Edited April 30, 2016 by Psykhaze

[Psykhaze]

Gave a SVN checkout to MIOS32 .
My eyes are now wide open ! (have i also seen a SID_V3 directory? )
Some great stuff out there. Makes me wanna code. And C code is easier to get community evolved.
Once again thanks to you all for driving me the good way. I waste less time.

Now i "officially switched" (ahah) to CORE32 i wonder a bit about displays > MBFM routing / envelopes / waveform display for example or new menu to access new features not accessible on a Control Surface
@Hawkeye Is there any other color backlight than blue on the newhaven screen you talked about ?
Is there any 2x40LCD sized with kinda same look?

Another general question : As i see a quartz on OPL3 / TIA / AY modules , are these quartz still useful with the new core or could a PWM signal from the core may replace them?
Good saturday evening to all,
JK

[Hawkeye]

Looking good and great choice with the STM32F4 core! :)

For the UI, it probably makes sense to really test out in the Ctrlr editor, which settings are altered most often - and put these on the CS.
With jojjelitos help, I am (still in the ongoing looooong process of) writing a MBNG/Programma template for the Yamaha FS1r. And I find it incredibly difficult on a FM synth to isolate the most important parameters for patch programming, even if you have lots of (encoder/knob) real estate on the CS. In that respect, I'd say: rethink the dual waveform switchers (they are kind of redundant) - but try to bring on most parameters for a single edited operator (vol, attack, sustain, decay, release, keyscale, waveform, multiplier, sustain/vib/tremolo, lfo1->vol, lfo2->vol, eg5->vol) on to the encoders/switches without any further switching. Then you can easily cycle through the four operators and adjust settings -> this should work out...

If you are going for that graphical display, some things can also be nicely configured there (e.g. the algorithm selector). But prepare for a lot of work, even if it is C-based... it is not a trivial project, but you surely know that by now! :-). I haven't seen other displays than the blue ones, but haven't looked thoroughly. Also, it is more of a green-blue, it is really nice... There are also awesome 4x20 character OLEDs out there, I have one (also in blue) on an old E-MU sampler (as a replacement), but these are also available in different colors. So if you want to go for the (easier-to-code-for) character-based display route, take a look at these 4x20 character OLED offerings (also other manufactorers than newhaven offer these, but I'd somehow stick with them. It is a hate-love by now ;-))

Many greets and enjoy the weekend!

Peter

 

[Psykhaze]

@Hawkeye
Based on your advice, i will try to invert Routing / Drum section in order to have a common "Waveform" part and more encoders availables, as some parameters are redundant between the 2 sections (and that's normal)
Will  add a led to the envelope selector (OP/EG5/Drum) too
Could you advice me about the quartz question for synthesis modules?
thanks in advance,
Jérôme

[Hawkeye]

Hi Jérôme,

awesome! Regarding the quartzes, best ask Sauraen - he definitely has most experience around here driving an OPL3 module from a 32-bit core! :-)

Many greets and enjoy!

Peter

 

[Psykhaze]

Hi again,
After some rework here is the last version of the frontpanel . More clear to me =) I let you see

Edit : Last hour corrections

Regards,
JK

•  

Edited April 30, 2016 by Psykhaze
Last hour edit =)

[Sauraen]

Glad to see you've seen the light of STM32F4! :)

I would recommend a few changes on the operator portion of the front panel:

• Since you have two rows of 4 knobs, put Attack, Decay, Sustain, Release on one row. (Also fix the spelling of Release)
• Volume and Multiplier are the two most important parameters in FM synthesis--on my synth they're at opposite ends of a row, but you might consider putting them next to each other.
• I can't comment on your EG>Vol/LFO>Vol knob because my synth does modulation differently.
• Key Scale is not one but two parameters. There's Key Scale Rate, a 1-bit parameter for how much quicker the EG is on higher notes; and Key Scale Level, a 2-bit parameter for how much lower the volume is on higher notes. They're both important for shaping your patch to work well throughout the whole keyboard range, but neither should be on a knob. KSR should be on a button/LED like you have Sus (you do understand what this parameter does, right?), Vibrato, and Tremolo; I guess KSL could be on a button+4LED thing like your Operator selector.

Some other thoughts:

• You seem to be implementing this like MIDIbox FM V1.4, where there are 6 4-operator voices and the percussion section. In reality, the OPL3 has 18 2-operator voices; 12 of which can be individually combined in pairs to form up to 6 4-operator voices, and 3 others of which can be combined to form the 5-drum percussion section. But this leaves 3 2-operator voices which can't be used with this scheme. This is the simplest solution, and I have to say that most of the complexity of MIDIbox FM V2.1 comes from the synth supporting arbitrary configurations of the 18 voices (within the OPL3's limitations), so I'm not sure I'd recommend you change your plan. But I just wanted to let you know what you're missing. :) Because the OPL3 has a number of waveforms (not just sine), you can make some pretty good sounds only on 2-operator voices; in fact I have almost a whole General MIDI patch bank completed, exclusively on 2-operator voices.

I am planning to make a video this evening going over the capabilities of the OPL3 and MIDIbox FM V2.1.

[Psykhaze]

Here the last corrections applied



regards,
JK

[Psykhaze]

Had some advices about rack format . In order to be able to fit 2 Control Surface PCB in lenght in a rack format (440mm) , i've reduced the general frontpanel format to 220 x 165 mm.
The PCB would be like 20mm less in lenght so 200mm width.
Here are the corrections

[Sauraen]

I think you got it backwards, Key Scale Rate is the 1-bit parameter and Key Scale Level is the 2-bit parameter.

One other thing, since switching between the operators is very common, you might want to consider having separate buttons to go to each operator, rather than one button to cycle through the four of them.

Also please consider watching the video I posted in the MBFM2.1 thread. :)

[Psykhaze]

@Sauraen I will look your video from the start to the end , please be sure of the that ! So kind from you to explain so much tings . Many things to get in it i'm sure =) Just looked the 2 first minutes at the moment.
Just was finishing some things before looking at it on calm.
I'll add the OP buttons and invert KSL/KSR.
Best regards,
Jerome

[Psykhaze]

@Sauraen Your corrections applied to CS

[NoellEagan]

Hi...i am a new user here. As per my knowledge the best way to design all of the parts from the beginning, so how the front panel works with the case, the connectors, heat management etc. I would propose sandwich-type connectors over the SIL ribbons used in the MB-6582. Much more durable and you can take the thing apart if needed. You can still use an angled case, just the IO will need panel mount or another PCB. Think about modular blocks, like OPL3 and Core8 sub-boards that plug into a CS. It's cheaper to buy multiple copies of PCBs rather than large ones and can make troubleshooting easier.

 

automated pcb assembly

Edited February 21, 2018 by NoellEagan

[Thomasch]

@Psykhaze
What happened to this project?
Was it abandoned?