tffshtt

port LPC1343 polysynth to MBHP_CORE_STM32F4?

88 posts in this topic

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...

Share this post


Link to post
Share on other sites

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 :happy:.... but I haven't worked that part out yet.

Share this post


Link to post
Share on other sites

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....

Share this post


Link to post
Share on other sites

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.

 

Morpheo_main_editor.png

Morpheo_ccgen_editor.png

Edited by cube48
1 person likes this

Share this post


Link to post
Share on other sites
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.

 

Morpheo_main_editor.png

Morpheo_ccgen_editor.png

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

 

Share this post


Link to post
Share on other sites

Morpheo is out. Sorry, no CC generator yet.

Share this post


Link to post
Share on other sites

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 

Share this post


Link to post
Share on other sites

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 by Redial
bad wording

Share this post


Link to post
Share on other sites

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 by yogi
follow up

Share this post


Link to post
Share on other sites

Many thanks yogi for answering my questions :happy:

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 :grin: (and recovering my arduino)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 by cube48

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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 by yogi

Share this post


Link to post
Share on other sites

@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;

 

1 person likes this

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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 :-)

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
Just now, Phatline said:

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

but after looking into the code, i think i cant modify it :confused:... 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. 

Share this post


Link to post
Share on other sites

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³

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now