[TK.]

MIDIbox FM V1.4 has been released!

From the ChangeLog:

MIDIboxFM V1.4
~~~~~~~~~~~~~~

   o PIC18F4685 only: CC assignment changes for Velocity/Aftertouch/Modwheel/WT
     are now non-destructive (shadow buffers are used for all parameters)

   o PIC18F4685 only: CC assignment names are now print on screen

   o changed velocity/modwheel/aftertouch depth parameter resolution to allow
     1:1 modulation of 4bit OP parameters.
     E.g. Depth=15, Init=0 will control the parameter from 0,,15 in positive direction,
     and Depth=-15, Init=15 from 15..0 in negative direction
     7bit parameters can't be modulated in full range anymore, but this is
     acceptable considered that OP parameters are more important to form the
     sound timbre.

   o Audio Channel selections now assigned to CC#13..CC#15 to avoid conflict
     with Panorama CC #10

Best Regards, Thorsten.

[Echopraxia]

I don't know what all that means but it sounds awesome!!

Now I really need to swap pics.

The OP changes you've made shouldn't mess with already programmed patches right?

Also my banksticks won't format or anything right?

Regards

[TK.]

Yes, correct!
If somebody really used CC assignments in the past, he has to double the depth value - thats all

Best Regards, Thorsten.

[Janis1279]

Hi Thorsten,

1. I made some changes in code for the pic18f4685 for the 4 x OP and 4 x INS buttons. These buttons look like working right now. But I don't know how correct are the code changes total(y).

the code part from the cs_menu_buttons.inc :
before:

;; CS_MENU_BUTTON_InsOP1
;; movlw 0
;; rgoto CS_MENU_BUTTON_InsOP_Cont

;; CS_MENU_BUTTON_InsOP2
;; movlw 1
;; rgoto CS_MENU_BUTTON_InsOP_Cont

;; CS_MENU_BUTTON_InsOP3
;; movlw 2
;; rgoto CS_MENU_BUTTON_InsOP_Cont

;; CS_MENU_BUTTON_InsOP4
;; movlw 3
;; rgoto CS_MENU_BUTTON_InsOP_Cont

changed to :

CS_MENU_BUTTON_Ins1
bcf CS_MENU_MODE, CS_MENU_MODE_INS_OP
movlw 0
rgoto CS_MENU_BUTTON_InsOP_Cont

CS_MENU_BUTTON_Ins2
bcf CS_MENU_MODE, CS_MENU_MODE_INS_OP
movlw 1
rgoto CS_MENU_BUTTON_InsOP_Cont

CS_MENU_BUTTON_Ins3
bcf CS_MENU_MODE, CS_MENU_MODE_INS_OP
movlw 2
rgoto CS_MENU_BUTTON_InsOP_Cont

CS_MENU_BUTTON_Ins4
bcf CS_MENU_MODE, CS_MENU_MODE_INS_OP
movlw 3
rgoto CS_MENU_BUTTON_InsOP_Cont

CS_MENU_BUTTON_OP1
bsf CS_MENU_MODE, CS_MENU_MODE_INS_OP
movlw 0
rgoto CS_MENU_BUTTON_InsOP_Cont

CS_MENU_BUTTON_OP2
bsf CS_MENU_MODE, CS_MENU_MODE_INS_OP
movlw 1
rgoto CS_MENU_BUTTON_InsOP_Cont

CS_MENU_BUTTON_OP3
bsf CS_MENU_MODE, CS_MENU_MODE_INS_OP
movlw 2
rgoto CS_MENU_BUTTON_InsOP_Cont

CS_MENU_BUTTON_OP4
bsf CS_MENU_MODE, CS_MENU_MODE_INS_OP
movlw 3
rgoto CS_MENU_BUTTON_InsOP_Cont

2. Where I can change the columns separation sign - " | ". Or how I can it correct to this view : " | ".
On the my LCDs I see "12" instead of " | " for the MBFM and for the MBSid.

In the previous MBFM v1_1 I deleted these signs in the cs_menu.inc , if I remember it true.

Thanks for your advice !

Regards,
Janis

This post has been edited by Janis1279: 08 March 2011 - 21:58

[TK.]

To 1) seems to be correct

To 2) really strange issue, I never saw this on one of my own LCDs.

However, there aren't so many lines which have to be changed:

mm:midibox_fm_v1 TK$ grep \'\|\' src/*
src/cs_menu.inc:	movlw	'|'
src/cs_menu.inc:	movlw	'|'
src/cs_menu.inc:	movlw	'|'
src/cs_menu.inc:	movlw	'|'
src/cs_menu.inc:	movlw	'|'
src/cs_menu.inc:	movlw	'|'	
src/cs_menu.inc:	movlw	'|'
src/cs_menu.inc:	movlw	'|'

Best Regards, Thorsten.

[Janis1279]

TK., on 13 March 2011 - 21:04, said:

To 2) really strange issue, I never saw this on one of my own LCDs.

However, there aren't so many lines which have to be changed:

mm:midibox_fm_v1 TK$ grep \'\|\' src/*
src/cs_menu.inc:    movlw    '|'
src/cs_menu.inc:    movlw    '|'
src/cs_menu.inc:    movlw    '|'
src/cs_menu.inc:    movlw    '|'
src/cs_menu.inc:    movlw    '|'
src/cs_menu.inc:    movlw    '|'    
src/cs_menu.inc:    movlw    '|'
src/cs_menu.inc:    movlw    '|'

Hi Thorsten,

Thank you very much for your help !

And the main instrument page view I changed, too

;; STRING 40, 0x00, "Ens.|I|Ptch|Name | Chn.|Audio"
STRING 40, 0x00, "Ens. I Ptch Name Chn. Audio"

I have Bolymin LCDs .

Best Regards, Janis

[Echopraxia]

Just wanted to know if the 18F4620 will work as well as the 18F4685 or even at all? The 4620 is my only spare chip besides my 18F452. I'm assuming I will have to hit up Smash but just wanted to confirm.

PS Do you think that MBFM would ever need to go core32?
Regards

[Imp]

I just found out, that it's possible to create phonemes by modulating the multiplicators.
I first did it with an external envelope which controls the CC, but then realised that it can be done within the FM via wavetables.
Unfortunately this is not as flexible and fun as with the external EG, so may i request CCs as target for the FM's EG and LFOs in a future release, please?


I'll attach a demo:

Attached File(s)

•  FMFormantAT.mp3 (385.81K)
  Number of downloads: 50

This post has been edited by Imp: 03 June 2011 - 10:51

[TK.]

Very clever! Thanks for the inspiration!

Quote

Unfortunately this is not as flexible and fun as with the external EG, so may i request CCs as target for the FM's EG amd LFOs in a future release, please?

Very difficult, as CC processing consumes too much time.
But I will think about a "slow-path" solution.

Best Regards, Thorsten.

[Hawkeye]

Hi,
very cool!

I don´t have a MBFM and dunno if it is already/at all possible, but what might be an option would be to have a dedicated formant sequence storage, that stores the center frequencies and other mbfm synth operator parameters and then is played back over time, just like the formant sequences of the FS1R from Yamaha (which has 128 to 512 playback steps per formant sequence, each step contains center frequency, volume, and formant-shape which equals the "width" of the spectrum emitted).

As data entry is not viable or really a lot of work, one could maybe use an existing formant converter, this one is in flash:
http://blog.zacharch...ditor-in-flash/
"well, excuse me, princess" <- very nice :-)
The converter is nice, because it also visualizes the formants and so explains a difficult procedure.
When looped, these sequences are able to create completely new (and evolving) un-fm-ish sounds, have a look at the "p11 Uuul-ha" preset for example.

The flash tool generates files for the FS1R (8 "voiced" + 8 "unvoiced" operators), but in my tests it already sounded quite good using only 3 or 4 "voiced" operators (all additive, flat fm algorithm).
I guess the generated sysex files may be parsed to strip excess operators and unavailable fm operator parameters for the opl3. If this would be realized, the very nice and professional formant sequences created by yamaha 12 years ago would be available for MBFM users...

Best regards,
Peter

This post has been edited by Hawkeye: 03 June 2011 - 00:46

[Imp]

TK., on 02 June 2011 - 23:33, said:

But I will think about a "slow-path" solution.

The WT is fast enough for this already, but i had to turn the rate up to 122.
A bit slower you hear the steppiness, faster and it seems to drop some steps on the way.

@Hawkeye: Sounds interesting, but you kinda distort the scale here
I can't imagine that these sounds are possible with the opl, e.g. because of it's integer multis.
All i could come up with so far were sounds like "Ja" or "Oi".

Btw, here's the patch:

Attached File(s)

•  FormantWT.zip (235bytes)
  Number of downloads: 14

[toneburst]

That formant patch is cool!

I don't know if this is the correct place for feature-requests for the next MB_FM application version, but..

How about an extra Velocity parameter for each operator? This would allow for more dynamic velocity-response, and the Velocity assignment at the Instrument level could be used for something else.

a|x

[TK.]

Each velocity assignment allocates 3 bytes for CC assignment, initial value and depth.
But the patch memory has only 4 bytes free. :-/

Best Regards, Thorsten.

[toneburst]

I see. Guess it's not going to happen, then. Thanks for getting back to me, anyway, TK.

a|x