-
Posts
15,198 -
Joined
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by TK.
-
-
-
Hi Johannes,
I've no comparison available for integer vs. float.
But if the required shift operation is your only concern, I assume that fixed point is still faster.
A shift operation (regardless how many bits) takes only 1 cycle.
See also: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439b/CHDDIGAC.html
I know that you don't like this tip, but anyhow: consider to use the special Cortex-M4 DSP instructions for fixed point operations (see also the bottom of the page that I linked above).
I guess that they can be embedded into C code by using intrinsics.
And in order to keep CPU independency, you could write another set of intrinsics which are doing the same operations with native C code.
Best Regards, Thorsten.
-
Sorry for the trouble! :-(
This was due to a corrupted build which can only happen with the special Makefile setup of MBSEQV4L (it uses some source files of the midibox_seq directory).
I fixed the release script, the binary is working now.
Version: V4L 082a
Best Regards, Thorsten.
-
The changes are now officially release in V4.082:
Best Regards, Thorsten.
-
In the last months I created many preliminary releases, it's time for a new official release: V4.082
From the ChangeLogs:
MIDIboxSEQ V4.080 ~~~~~~~~~~~~~~~~~ o SELECT+PASTE transfers the parameter layer, which was active during COPY, to the current parameter layer. If a drum track is selected, it's doing this for the trigger layer (and not for the parameter layer). o SELECT+CLEAR clears only the current parameter layer. If a drum track is selected, it's doing this for the trigger layer (and not for the parameter layer) o it's now possible to control the track steps with CCs. Each track has a dedicated CC which has to be configured in the MIDI->Ext.Ctrl page. o it's now possible to turn off the track clock by enabling the new "Manual" mode in the DIVIDER page. Once enabled, a step will only be played if: - manually triggered in the MANUAL page - set with the new CC based step control feature (MIDI->Ext.Ctrl page) Use cases: - predefined MIDI events, stored in the track layers, should be manually triggered (and not sequenced). E.g. in conjunction with a sampler, you could set each step to a note which "fires" a certain sample. In addition, you can fire CCs, Program Change, Aftertouch etc. from the MANUAL page. - the track should be controlled from an analog modulation source (e.g. a sawwave from a LFO). MIDIbox SEQ doesn't provide analog inputs, so that an external CV-to-MIDI interface is required. Note that this interface also has to scale the CC value over the desired step range. If the modulation source should sweep over step 1..16, then the CV-to-MIDI interface has to scale down the converted value to the CC value range 0..15!
MIDIboxSEQ V4.081 ~~~~~~~~~~~~~~~~~ o added USB MIDI workaround for Windows o fixed synchronisation issue in Song mode
MIDIboxSEQ V4.082 ~~~~~~~~~~~~~~~~~ o Options in LIVE page are now stored in session specific MBSEQ_C.V4 file o initial release for MBHP_CORE_STM32F4
Best Regards, Thorsten.
-
The new handling is officially released now because I'm happy with the implementation! :)
->
Best Regards, Thorsten.
-
The new version V4L.082 provides a new CLEAR button and sequence recording handling based on this discussion with Florian:
MIDIboxSEQ V4L.082 ~~~~~~~~~~~~~~~~~~ o CLEAR button now allows to clear individual tracks with the GP buttons: - CLEAR+SEQ1: clear entire Seq1 + configuration (*) - CLEAR+SEQ2: clear entire Seq2 + configuration (*) - CLEAR+GP1: clear note triggers (values are kept but not played) - CLEAR+GP2: reset velocity values to 64 - CLEAR+GP3: reset note length values to half step - CLEAR+GP4: clear Track 4 (Pitchbend + last CC lines) - CLEAR+GP5: clear CCs of Track 5 - CLEAR+GP6: clear CCs of Track 6 - CLEAR+GP7: clear CCs of Track 7 - CLEAR+GP8: clear CCs of Track 8 Same for GP9..16 for Seq2 (*) track configuration won't be changed if 'PasteClrAll' set to 0 in MBSEQ_GC.V4 file o changed the track and layer assignment algorithm for CCs in recording mode: Previously new CC lines were recorded into Track 4, Layer B upwards. Now they are assigned the following way: - 1st CC line is recorded into Track 5, Layer A - 2nd CC line is recorded into Track 6, Layer A - 3rd CC line is recorded into Track 7, Layer A - 4th CC line is recorded into Track 8, Layer A - 5th CC line is recorded into Track 8, Layer B - 6th CC line is recorded into Track 8, Layer C - 7th CC line is recorded into Track 8, Layer D - 8th CC line is recorded into Track 7, Layer B - 9th CC line is recorded into Track 7, Layer C - 10th CC line is recorded into Track 7, Layer D - 11th CC line is recorded into Track 6, Layer B - 12th CC line is recorded into Track 6, Layer C - 13th CC line is recorded into Track 6, Layer D - 14th CC line is recorded into Track 5, Layer B - 15th CC line is recorded into Track 5, Layer C - 16th CC line is recorded into Track 5, Layer D - 17th CC line is recorded into Track 4, Layer B - 18th CC line is recorded into Track 4, Layer C - 19th CC line is recorded into Track 4, Layer D Same for Track 12..16 for Seq2 Advantage: if only a few CC lines are recorded, we've dedicated tracks for PitchBend and CCs (Track 4-8, Layer A) which can be individually muted and cleared. Additional CCs populate the remaining layers from Track 8 backwards, so that PitchBend remains an individual track if not more than 17 CC lines are recorded.
Best Regards, Thorsten.
-
The meta events are finally implemented: http://www.ucapps.de/mios32/midibox_ng_v1_030_pre4.zip
So, there is an individual pitchbend (14bit or 7bit) for each CV channel which controls the fine pitch over the configurable pitchrange
And there are individual octave and semitone transpose values for each CV channel as well.
The example forwards the configuration value from EVENT_RECEIVERs to EVENT_SENDERs.
Of course, you could also control the values from another source, e.g. forward from EVENT_AIN to EVENT_SENDER which then performs the meta operation.
Best Regards, Thorsten.
-
Hi Johannes,
the numbers came from the EEMBC benchmarks linked above, but I wouldn't take this comparison too serious for your application.
E.g. if STM32F4 would only process 8bit values, the benefit isn't so high.
Or if a benchmark just toggles a pin, it could be that the performance is almost the same depending on the peripheral bus architecture ;-)
The truth is typically in the middle...
Anyhow, as you already mentioned above, STM32F4 provides features such as 32bit calculation and DMA, which are advantageous for the use case, and if it turns out that it isn't possible to replace all Atmel CPUs, just take a cheap second one... :smile:
There are some apps and tutorials in the respository which give you a good entry:
- Output audio via the I2S based DAC in 024_i2s_synth: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F
- C++ based synth engine (w/o audio, only controllers like LFO, ENV, etc): http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v3%2F
- another C++ based CV engine: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fprocessing%2Fmidibox_cv_v2%2F
- simple project to output audio samples: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsynthesizers%2FSD+card+sample+player%2F
We've no specific application which would really get use of the STM32F4 processing power while generating audio - you are in the pole position! :smile:
Best Regards, Thorsten.
-
I like such tutorials! :thumbsup:
Best Regards, Thorsten.
-
Today I spent some hours to make the WebSVN download button working - without success!
This seems to be related to some webserver security settings. Due to my limited knowledge about such topics (I don't want to open a security hole!!!), I've disabled the download button now.
Only proper way to download files is via a SVN client, such as Tortoise under Windows, or "svn" under MacOS/Linux.
Currently only the global settings can be saved from the SCS.With the latest sources we are now able to save/load patches from the SCS! :)
- move the SCS encoder or trigger GP button #2/3 to select the current patch
- store/load a patch under Menu->Disk->Patch
- A001 is loaded after startup
Best Regards, Thorsten.
-
Very cool! :smile:
I gave you access to the hidden programmers section of this forum: http://midibox.org/forums/forum/41-programmers-lounge/
I can give you SSH access to the subversion server so that you can upload your code for easier sharing :smile:
Best Regards, Thorsten.
-
A 4x40 display requires a second CS output and some software changes.
This isn't supported.
Best Regards, Thorsten.
-
Thorsten, do you need a sample? Should I send you one or two of them?
If you could send me a sample, this would be great; it would be a nice test vehicle for me.
Best Regards, Thorsten.
-
Hi,
from my point of view, this is possible, but mainly depends on the effort you want to spend for the implementation.
Performance-Wise the STM32F4 is a beast, this is what several MIOS32 benchmarks are showing.
Typically STMF4 is 2 times faster than a LPC1769, and 3.5 times faster than a STM32F1
Compare against ATmega: see for example EEMBC benchmark comparison charts: http://www.eembc.org/benchmark/index.phpTypically STM32F4 is 5..6 times faster than a ATmega644You are right, that by moving to a 32bit architecture additional performance improvement can be expected, and you can take advantage of it and increase the sample rate & accuracy.If performance is still not sufficient, then consider to replace timing critical routines by hand optimized assembly code.This is what Xavier did in his Preen2 FM project: http://ixox.fr/preenfm2/Best Regards, Thorsten. -
I debugged this again and finally found the root cause: loading the 4 patterns took more time than expected, therefore the last pattern was sporadically out-of-sync depending on the CPU load.
The pattern load is now running with higher priority (2 times faster) which should solve the issue.
Could you please check this at your side?
-> http://www.ucapps.de/mios32/midibox_seq_v4_081_pre4.zip
Best Regards, Thorsten.
-
Is there a chance to get more brightness without connecting each LED individually?
No, because in a 8x8 DOUT matrix the LEDs are only activated for 12.5% of the time
The brightness also depends on the LEDs you are using.
A "blacklist" (which also lists the good ones) can be found here: http://www.midibox.org/dokuwiki/doku.php?id=mb-lre8x2cs_pcb
Best Regards, Thorsten.
-
Not really (too difficult)
I could provide a save_patch and load_patch command in the terminal if this helps
The first patch will be loaded automatically after startup - and will then contain your default settings.
Best Regards, Thorsten.
-
The DAC pins are not available at J10B, but on the STM32F4DISCOVERY board.
See http://www.ucapps.de/mbhp/mbhp_core_stm32f4.pdf
search for "Audio DAC"
Best Regards, Thorsten.
-
I tested it on a V4L yesterday.
Please try the latest version: http://www.ucapps.de/mios32/midibox_seq_v4l_082_pre3.zip
Best Regards, Thorsten.
-
Thanks for the files!
I was able to reproduce the sync issue at my side, but after 1 hour of analysis I still haven't fully understood why it happens.
However, I found a workaround which might be acceptable: if a pattern is already loaded and actively running, it won't be reloaded anymore.
I guess that most users will prefer this handling anyhow, because interactive changes in the pattern won't get lost.
Please try this version: http://www.ucapps.de/mios32/midibox_seq_v4_081_pre3.zip
Best Regards, Thorsten.
-
Than longer I'm waiting, than better ideas... ;-)
Meanwhile I think that the best way would be to give direct access to the AOUT_PinSlewRate*, AOUT_PinPitchRange*, AOUT_PinPitch* functions of the AOUT driver via meta events, so that any controller could change them directly.
TODO marker
Best Regards, Thorsten.
-
The most simple strategy would be the following:
- download the repository into a separate directory and change your MIOS32_PATH accordingly
- change the PLL frequency configuration in mios32/STM32F4xx/mios32_sys.c, because STM32F401 can only be clocked at 84 MHz
I assume that the corresponding SFR configuration can be found somewhere in the internet
- compile a new bootloader under bootloader/src with "make STM32F4DISCOVERY"; this will refresh mios32/STM32F4xx/mios32_bsl_STM32F4DISCOVERY.inc
(this step requires a perl installation)
- recompile bootloader/updater and program it into the flash
If this already helps, let me know about the changes and I will consider MIOS32_PROCESSOR=STM32F401VC in the main branch, so that you can use a common repository again.
Best Regards, Thorsten.
-
You've to connect the analog input, Gnd, Vss, touchsensor as well.
So, actually really a nice work. :)
Best Regards, Thorsten.
MIDIbox NG Release + Feedback
in MIDIbox NG
Posted
Let's call it an imperfection... ;)
In this version inverted and reduced ranges should be supported properly: http://www.ucapps.de/mios32/midibox_ng_v1_030_pre5.zip
Rotated LCD view: would only work with graphical LCDs, and would require a special LCD driver (not the universal one) which has to be developed for the specific display.
The driver would also consume some memory (which has to be removed from the pool), since direct writes to the display are not possible anymore.
And it would slow down display output.
So: not supported from my side.
Best Regards, Thorsten.