Jump to content

TK.

Administrators
  • Posts

    15,198
  • Joined

Posts posted by TK.

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

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

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

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

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

  6. The meta events are finally implemented: http://www.ucapps.de/mios32/midibox_ng_v1_030_pre4.zip

     

    Usage example: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fcvtransp.ngc

     

    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.

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

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

  9. 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.php
    Typically STM32F4 is 5..6 times faster than a ATmega644
     
    You 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.
     
  10. 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.

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

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

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

×
×
  • Create New...