port LPC1343 polysynth to MBHP_CORE_STM32F4?

[arumblack]

Had a few minutes extra today, and a few spare STM32F4 Discovery modules, so I uploaded the MIOS GOOM port and had a muck around with it. I was wondering if anyone has stuck this thing on a MIOS32 core module and made a control surface for it yet? Is there a tested and true config yet? I havent poked into the code yet, and I'm not much of a coder myself but I can hack through it, just didn't want to reinvent the wheel.

 

And thanks for the work on this thing! pretty Pretty cool to get a 16 voice multitimbral Hardware synth for 15 bucks...

[thumper]

I've had my eye on this also for a while but like you haven't got stuck into it yet. At first I thought about using pots with an ainser module on channel 1 like the original.... but banked encoders with switches (or another detented encoder?) to select each channel/layer may be better. I had a quick browse through the Midibox NG documentation and this seems fairly straight forward as described in the first steps chapter. I think you use the snapshot function to store/recall parameters for each layer for 'blow your socks off!' style polyphony .... but I haven't worked that part out yet.

[arumblack]

its got 16 voices, and 16 channels, is each voice monophonic or can you sacrifice channels for polyphony?

 

Is there somewher to download some patches to play with? I don't have access to a midi controller for a couple days and using MIOS studio to try to edit patches works but isnt great.....Guess I could make a controller in ableton live or FL studio....

[cube48]

The polyphony is allocated dynamically. So you can play 16 different monophonic sounds or 16 voices in one sound/channel or anything in between. I didn't encounter it yet but there will be some voice stealing going on when you reach the limit.

I intend to publish my Pure Data control surface soon. I'm debugging the extra CC generator and have to update the documentation but it's very close.

It's called Morpheo and will give you:

• ability to edit all Goom synth params from the control surface ... well ... except Sustain which you can feed into it from your controller with Sustain switch
• switch between MIDI channels and edit the channel patches separately - switching the channels will store the current edits into 'channel patch' and is saved within PD file
• store up to 256 different sounds/patches (16 banks x 16 patches) with quick access to load and store functions
• morph (or interpolate if you want) dynamically between current patch and one chosen from the library with Morph fader (mapped to CC1 - ModWheel); you can exclude some parameter groups from the morphing so you avoid drastic changes in the sound (i.e. switching the OSC interaction mode) if you wish so
• apply 4-segment flexible envelope/lfo to one parameter on one channel only from the separate MIDI CC Generator (modified version of cc gen PD patch I found on the net) - cc gen will have it's own patch library of shapes/envelopes
• will come with 64 patches I made during the development
• will come with documentation but it should be easy to grasp

Screenshots are attached. I hope to release it very soon. I never used Git but want to publish it on GitHub so anyone can improve or modify it.

 

Edited March 11, 2016 by cube48

[yogi]

6 hours ago, cube48 said:

The polyphony is allocated dynamically. So you can play 16 different monophonic sounds or 16 voices in one sound/channel or anything in between. I didn't encounter it yet but there will be some voice stealing going on when you reach the limit.

I intend to publish my Pure Data control surface soon. I'm debugging the extra CC generator and have to update the documentation but it's very close.

It's called Morpheo and will give you:

• ability to edit all Goom synth params from the control surface ... well ... except Sustain which you can feed into it from your controller with Sustain switch
• switch between MIDI channels and edit the channel patches separately - switching the channels will store the current edits into 'channel patch' and is saved within PD file
• store up to 256 different sounds/patches (16 banks x 16 patches) with quick access to load and store functions
• morph (or interpolate if you want) dynamically between current patch and one chosen from the library with Morph fader (mapped to CC1 - ModWheel); you can exclude some parameter groups from the morphing so you avoid drastic changes in the sound (i.e. switching the OSC interaction mode) if you wish so
• apply 4-segment flexible envelope/lfo to one parameter on one channel only from the separate MIDI CC Generator (modified version of cc gen PD patch I found on the net) - cc gen will have it's own patch library of shapes/envelopes
• will come with 64 patches I made during the development
• will come with documentation but it should be easy to grasp

Screenshots are attached. I hope to release it very soon. I never used Git but want to publish it on GitHub so anyone can improve or modify it.

 

Very cool. PD is a great choice; open source cross platform tools are very welcome.

I like your R Pi setup as well as your Moon Box :) Haven't gotten into the R Pi but very temped ( SunVox, Milky Tracker, retro EMUs; so many interesting directions);  just trying to get over the 'sticker shock' for the touch screens (pushes the cost up to that of a used IPad 1 or 2). For a 'Ghetto' build maybe a HDMI to VGA adaptor and a second hand VGA monitor.  At least till I feel comfortable buying a TS setup.

Looking forward to your patch,

Yogi

 

[cube48]

Morpheo is out. Sorry, no CC generator yet.

[yogi]

Thanks :) Will be trying this out soon, got a R Pi 2 a week ago and waiting on a HDMI to VGA dongle. Also got a Logitech USB audio dongle, at some point will upgrade to the HiFiBerry DAC+ but kind of want to see what can be done on the cheap. 

Yogi 

[Redial]

Hi, I really appreciate the port work cause now I have my first synth :)

I have a question, is it possible to add knobs and switches like in the original build?

I like to build a case like the one from the creator, the only option that I manage to make myself is to use an arduino that I already have as a midi controller connected to a usb hub so I don't lose the option of a keyboard, I find it a better option to do it on the SMT board but I barely know C let alone Assembly :(

From what I understand the original front panel only controls channel 1, is that selectable?

Many thanks I´m already enjoying your awesome work :D

Edited April 27, 2016 by Redial
bad wording

[yogi]

Welcome Redial. It should  be possible to add to the basic port, as there are all the MIOS hooks in the port and the Cpu is only loaded to ~40%. I don't think the FP code from the original LPC Groom is ported as it wouldn't work at all on the STM board. If you wanted to dig into MIOS programming and add to the hooks for knobs or switches, work through the examples on the wiki http://ucapps.de/mios32_c.html ; they cover the full range of tasks needed for a basic panel and are all C. You would need some DIn and DOut boards and add the code to tie them into the synth code

The idea of using an Arduino as a midi input is useable. It could be done also with Midibox HW but if you are more comfortable with the AVR, go with that. The way I would try is to connect the Arduino via a direct TTL level serial midi link to one of the MIOS midi ports (no need for opto couplers, just Tx to Rx/ Rx to Tx connections). This would allow a USB keyboard as well as a knob panel. It should be OK with a +5V Arduino as the STM is +5 tolerant. You would still need to add some MIOS code linking the serial midi in (or is serial midi already supported in the port?) the same way the USB midi is handled, but it should be straight forward. At this point you could also add the other serial midi ports of the STM, allowing more external midi sources :)

EDIT: Took a look at the Groom synth app.c scr-

/////////////////////////////////////////////////////////////////////////////
// This hook is called when a MIDI package has been received
/////////////////////////////////////////////////////////////////////////////
void APP_MIDI_NotifyPackage(mios32_midi_port_t port, mios32_midi_package_t midi_package)
{
  // -> synth
  SYNTH_MIDI_NotifyPackage(port, midi_package);
}

So this seem to pass any incoming midi, both USB and serial, to the synth. Looks like you will only have to worry about the connections to get things running :)

EDIT2: Just to confirm, the UART Midi default ports are indeed working. Any midi events on USB0, UART0 or UART1 are forwarded to the synth engine. 

Yogi

Edited October 31, 2016 by yogi
follow up

[Redial]

Many thanks yogi for answering my questions

I think I'm gonna try a quick prototype with arduino then work my way through the MIOS examples for a less power hungry synth  (and recovering my arduino)

[yogi]

Cool, glad to help a little. Getting to know MIOS will really be worth the time. It's a very mature package for doing these types of projects. Unlike the close to bare metal of the Arduino, MIOS is a real time OS with built in tasks for midi/synth use. This allows the user to concentrate on programming just the functions that are needed for the specific application. 

Have fun, yogi

[cube48]

Can anyone give me a hint on building the Goom firmware please?

I have two issues.

1) I'm trying to amend the source code to get the 24 semitones of pitch bend to make full use of Linnstrument's pitch slides. Having no C coding skills I managed to find two possible spots in synth.c file.

Line 191 mentions original +/- 2 semitones setting but I don't know if it's the right place to do the change and how to update the formula to get 24 semitones.

  u+=pbend[v->chan]/12;      // gives +/- 2 semitones

Line 392 seems to have something to do with pbend as well.

pbend[midi_package.chn]=(midi_package.evnt2<<7)+midi_package.evnt1-0x2000;

I get it that 0x2000 is normally resolution of the pitch bend (8192 in decimals).

Which place is the right to update?

2) I'm getting this error when building the Goom.

.
..
...
....
.....
Creating object file for notestack.c
Creating object file for mini_cpp.cpp
Creating object file for freertos_heap.cpp
Creating object file for wave.s
sed: can't read project_build/src/wave.dd: No such file or directory
make: *** [project_build/src/wave.o] Error 2

If i re-run the build without deleting incomplete project.hex it finishes successfully but resulting file is smaller than the functional one from this thread. And of course is not working. If I'm understanding it correctly, the project_build folder and it's content is created during the 'make' process. I don't know how to make sure that the wave.dd file gets to it's place.

Thanks for any help!

P.S.: Goom with Linnstrument is already a lot of fun even with +/-2 semitones PB :-D

Edited May 16, 2016 by cube48

[cube48]

Problem still persists. I've set up a build environment on another machine (AVLinux, 64bit) and getting similar error. It seems that the source code of Goom port is broken somehow because other midibox apps are being built fine.

Creating object file for wave.s
sed: can't read project_build/src/wave.dd: No such file or directory
/home/cube48/midibox/mios32/trunk/include/makefile/common.mk:172: recipe for target 'project_build/src/wave.o' failed
make: *** [project_build/src/wave.o] Error 2

Is anybody else able to build the Goom from source available in MB SVN repository?

[yogi]

On 7/28/2016 at 3:53 AM, cube48 said:

Problem still persists. I've set up a build environment on another machine (AVLinux, 64bit) and getting similar error. It seems that the source code of Goom port is broken somehow because other midibox apps are being built fine.

Creating object file for wave.s
sed: can't read project_build/src/wave.dd: No such file or directory
/home/cube48/midibox/mios32/trunk/include/makefile/common.mk:172: recipe for target 'project_build/src/wave.o' failed
make: *** [project_build/src/wave.o] Error 2

Is anybody else able to build the Goom from source available in MB SVN repository?

Hey don't know if you solved this, but just ran across this same issue in another thread-

It seems that fix was a roll back to an older Makefile. There wasn't a follow up as to if this effected the apps operation, but 'no news is good news' may apply (?)

Yogi

EDIT- OK so I went ahead and tried test builds with the current Makefile and the suggested older version. Both fail on the first try and succeed when re-running make ( with no cleanup). Both .Hex files are  181KB, which is larger then the the 179 KB .hex in ~\release\ STM32F407VG\ in the SVN. Not sure about the 2 KB difference between the SVN and these local builds.

EDIT2- just compared both the 181 KB .hex files with HxD and they are identical. So the changes to the makefile didn't change anything with the build ( but there is still the difference between the SVN version).

Edited October 7, 2016 by yogi

[tffshtt]

@cube48

Sorry I just got around to asking mark about the increasing the bend amount.  He said to divide by 2 to double the bend range.  e.g. a value of 6 should get a range of 4

On 16.5.2016 at 1:09 AM, cube48 said:

u+=pbend[v->chan]/12;

 

[yogi]

So I finally loaded up my local hex build (181K in size) that I wrote about above and it works just as great as the precompiled hex (179K). This was as much a test of my toolchain install (just recently had to set it up again) as a test of the Goom scr.  

I assume that the change in size of the two hex files is due to slight changes to the MIOS32 core functions (?) 

Yogi

[cube48]

On 29. 10. 2016 at 1:04 PM, tffshtt said:

@cube48

Sorry I just got around to asking mark about the increasing the bend amount.  He said to divide by 2 to double the bend range.  e.g. a value of 6 should get a range of 4

 

Thanks a lot! That's really valuable info. I hope to get my build toolchain set correctly so I can try to compile it again.
I'm curious if the values can have decimals/cents. I.e.:

6 = 4 semitones
3 = 8 semitones
1.5 = 16 semitones
1.125 = 24 semitones...?
0.75 = 32 semitones

It can be totally false assumption... I desperately suck at math :-)

[yogi]

7 hours ago, cube48 said:

Thanks a lot! That's really valuable info. I hope to get my build toolchain set correctly so I can try to compile it again.
I'm curious if the values can have decimals/cents. I.e.:

6 = 4 semitones
3 = 8 semitones
1.5 = 16 semitones
1.125 = 24 semitones...?
0.75 = 32 semitones

It can be totally false assumption... I desperately suck at math :-)

Not really sure, but the fractional factors may violate the data type (?)

Also, at one point I was having an issue with the toolchain install that sounds similar to what you are seeing, hex too small. It boiled down to not having one (can't recall which) Env Vari not set correct. I ended up adding all of MIOS32 EVs to my System Variables rather than setting them from the CLI (I'm using XP SP3 and Notepad++ with a Make macro). It was one of the "MBHP_CORE_STM32F4: " specific set I think. I was trying to use the 

set MIOS32_GCC_PREFIX=arm-none-eabi....

in the NP++ Make macro but XP was not having it, so ended up with a more permanent setting.

Yogi

[yogi]

So here is an open question to all: what would be your preferred CS for this little beast? ATM I'm messing with the source and got a proof of concept LCD display going. It not very useful, just displays the current VCA Level. I'm planning to add some sort of CS controls and patch storage. 

I lean towards a knob per voice pram (21 + two toggling switches for the FM and FREQ Md ) and switching between the 16 voices. At the very least will add some sort of midi feedback function (to keep editor softs updated with the local controls).

Just starting but would like to hear opinions,

Yogi

LCD1project.hex

[Phatline]

...a 3rd OSC, and i would use it...

but after looking into the code, i think i cant modify it ... dont know assambler

[yogi]

Just now, Phatline said:

...a 3rd OSC, and i would use it...

but after looking into the code, i think i cant modify it ... dont know assambler

Kind of in the same boat with ARM assembler. Maybe some day...

BUT adding some other stuff like an arp, echo or lfo seems do-able. 

[Phatline]

when doing the patch saving, inside the machine, then a Patch-CC-Output for external Midi CC would be nice (as you said), in this case a preset morph between patches is a good idea, but maybe not easyly done.

For me it is enough to save the preset cc in a external Controller, and dump it into the Synth when loading it... in this case i can more easyly automate CC and morph presets... because can doing in C ;) ... but of course Midi-Traffic³

[yogi]

Would have to look at examples of morphing for ideas :)

I'm using the Goom Ctrlr Panel now which works for the most part but it's save functions (or the really old Ctrlr version I have to use) are a bit of a mess. No easy way to assign one voice's patch to another voice, some issues with updating when switching between patches and patch names don't work. So by adding a CS to the synth, we are ~ 80% of the way to being able to natively save and recall patches, I think (it's really great coding against MIOS32). Using a MBHP 'F4 Core board is a nice addition to the bare synth, breaks out everything for easy expansion.

With patches saved on the HW we can use Prog Change messages for favorite patches and gain independence from the Computer (although I like the idea of a RPi front end). 

For awhile, and maybe still, had planned on using another core running NG for a CS. But a single 'F4 solution is very attractive to me.  Even if it's a bit minimal like a Shruthi, we can still control it with midi or, with more effort, directly from the CS.

Anyway, I think I'm getting ahead of myself. Need to get a few encoders hooked up and play some :)

Yogi

[TK.]

To the .s file issue: it works at my side with the latest Makefile

Under which OS are you trying to build the project?

Best Regards, Thorsten.

[yogi]

For myself - XP SP3, fails first time after Clean All but compiles fine, and runs, thereafter with either change (Thumb as source or ARM as source=scr/wave.s) to Makefile 2178 2015-05-25. Hex file ~2K bigger (181K) than pre-compiled project.hex (due to MIOS32 core updates since 2015?). Other projects compile without problem but also a little larger.

Yogi