Jump to content

TK.

Administrators
  • Posts

    15,198
  • Joined

Posts posted by TK.

  1. Thanks!

     

    I was able to reproduce the "multiple mixer map dump" issue, it should be fixed in this version:

    http://www.ucapps.de/mios32/midibox_seq_v4_084_pre2.zip

     

    But the strange "track step" behaviour still puzzles me.

    It doesn't happen at my side (resp. I don't recognize it because I don't know your tracks good enough, or I'm not using the same instruments...)

     

    Theoretically it can't happen, because a sequencer start will reset all variables which belong to the step progression.

     

    There is only one (known) way how this could happen: if an external device changes the song & pattern position with the appr. MIDI Event (0xf2)

    So: is there any device connected to MIDI IN which could send a 0xf2 event?

    If you are unsure: disconnect all devices from the MIDI IN ports.

     

    Best Regards, Thorsten.

  2. The first song from my song page, plays normally when I press play (consider 16 steps 1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16) .

    But, after I push stop and try to play it again it plays in this order 13-14-15-16-1-2-3-4-5-6-7-8-9-10-11-12 and never plays the song in the right order.

     

    Do you mean song steps (A1, A2, .. A8, B1, B2, ... B8) or track steps?

     

    If song steps: it's normal that MBSEQ starts a song from the currently displayed position to simplify editing.

    Just change to another page (e.g. EDIT) and push the start button from there - then the song should be started from A1

     

    If you (and/or some other) people don't like this behaviour, I could make it optional.

     

     

    In this release, something is happening with midibox FM. In the second song for exeample, I send a patch change to Fm, but when I play the song, the patch is changing 3 times in an aleatory way and stops at a wrong patch.

     

    This is strange!

    I need your session directory, and the MBSEQ_GC.V4 file in the root directory to analyze this.

     

    Best Regards, Thorsten.

  3. I'm a bit confused from your reply and guess, that you missed the message:

    you can modulate all six OSCs with a single modulation path by enabling the L/R switches of the direct modulation targets for OSC pitch.

    This will copy the modulation result to all (selected) targets.

     

    Did you every try this - where is the difference?

     

    Best Regards, Thorsten.

  4. The breakout board is not an external board, it just brings all interfaces together and allows to mount the MBHP_CORE_STM32F4 (or MBHP_CORE_LPC17) under the frontpanel at the bottom of the case without tricks and with much more free space.

     

    Here a picture from orange_hand which shows what I mean:

    post-3436-0-03141400-1402946049_thumb.jp

     
    Original article (in german): Re: Midibox Sequenzer MBSEQ V4 / The Project

     

     

    Anyway if the Heidenreich order is already confirmed why not just go and think about possible STM32F4 changes later on?

     

    I'm trying to highlight that there is a solution which makes LPC17 and future STM32F4 users happy.

    Such a breakout board would even open the possibility to upgrade the MIDIbox SEQ with future core modules w/o high costs, because most interface components are already part of the breakout board. We wouldn't have a dependency between the core module layout and the backpanel anymore.

     

    Best Regards, Thorsten.

  5. Hi,

    the DEFAULT_BPM_DIGITS_* configuration looks correct for your hardware.

    Could it be that the common lines are connected to the wrong Dx output pins?

    I'm a bit unsure if it was (D7, D6, D5) or (D2, D1, D0)

    Best Regards, Thorsten.

  6. It's started, but not finished, see: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fprocessing%2Fmidibox_cv_v2%2Fsrc%2Fcomponents%2FMbCvVoice.cpp

     

    1st place: search for "transfer note -> linear frequency"

     

    2nd place: search for "linear frequency -> CV frequency conversion"

     

    It won't be so easy to finalize this, if you would like to work on the implementation, step forward. :)

     

    Best Regards, Thorsten.

  7. As mentioned in another thread, I highly recommend to use a MBHP_CORE_STM32F4 module, since this will be the only one which will be able to run the upcoming "V4 Plus" firmware (due to higher amount of RAM and Flash resources, and higher speed).

     

    Accordingly the backpanel will look different.

     

    E.g. MBHP_CORE_STM32F4 natively supports 4 MIDI INs and 4 MIDI OUTs - is there still a need for 4 additional IIC based MIDI OUTs?

     

    For SD Card and USB Socket we need a breakout board, because the MBHP_CORE_STM32F4 module is too large so that it can't directly mounted at the backpanel (/edit: to be more precisely - instead it has to be mounted at the bottom of the case)

     

    For ethernet the MBHP_ETH module would be required.

     

    This opens the option that somebody designs a special breakout board with:

    - 4 MIDI IN/OUT based on two MBHP_MIDI_IO boards

    - USB, and here the question: do you prefer a B Socket like before, or would Micro USB be more interesting - advantage of Micro USB: an USB Host option would be possible!

    - SD Card Socket

    - Ethernet Circuit (MBHP_ETH module) + Socket. For LPC17 a direct socket connection would be required (MBHP_ETH not used)

    - 25 pin AOUT/SRIO Breakout Socket
      Optionally with line drivers to support cable lengths of up to 5m -> http://www.ucapps.de/mbhp/line_drivers.pdf

    - BLM Socket

    - Power Switch and Ext. Power Socket

     

    Such a breakout board would have another advantage: it would be compatible to the MBHP_CORE_LPC17 module as well!

    And we could create a common backpanel design for it.

     

    Best Regards, Thorsten.

  8. Yes, you need two MBHP_DIO_MATRIX modules, yes, these are 1N4148 diodes, and yes the LEDs are driven similar to the LED Ring schematic.

     

    Note that the 10x10 dimension isn't the best choice, because LEDs won't be so bright like on a 8x8 configuration.

     

    Best Regards, Thorsten.

  9. Well done!  :thumbsup:

     

    I don't know if this is a known thing, but I suspect that this might be common to Atmel processors when delivering PWM at that sort of frequency? I"m guessing that the PWM coming from the PIC is much closer to a square wave and the edges don't overshoot 0 or 5 volts?

     

    It seems that the Atmel microcontroller has much "stronger" pad drivers compared to the PIC which can lead to such EMC issues.

     

    This might also explain why the 6581 was working: it's produced in a different technology which consumes more power. Probably the input resistance of the clock input is lower, and this causes the same effect like the cap that you've added.

     

    The proper solution would be (if my assumption is correct) to add a resistor in serial, e.g. 100 Ohm should be fine.

    It will limit the current drawn during signal transitions so that the nominal voltage isn't exceeded.

     

    Using a cap is also possible, but not the best choice, because it will cause higher current drawn during transitions (no dramatic drawn, not really noticeable, but if you ask for the preferred solution, take the resistor)

     

    Best Regards, Thorsten.

  10. Hi,

     

    it should work the following way: configure the encoder, so that it doesn't send a value.

    The integrated button has to execute a .NGR script section.

     

    From there you could send the current encoder value - e.g. here for encoder 1 (ENC:1)

    #    type          port chn value
    send ProgramChange USB1   1 ENC:1
    

     

    Icing on the cake would be if I scroll through the list but don’t press the switch, the value on the display jumps back to the current value after a few seconds.

     

    Unfortunately timed events are not supported.

     

    Best Regards, Thorsten.

  11. It's interesting, that the other guy was using an Atmel chip as well, and had (or still has?) the same issue.

     

    I would propose to check the shift register transfers.

    Write a routine which allows you to set different data values at the shift register output, e.g. controlled via incoming CCs or MIDI Note events (so that you don't need to change your program while testing different values).

    Check that you can control each individual bit of the address and data lines, and that there are no interdependencies.

     

    E.g. if it turns out, that the gate flag (D0) doesn't work reliable, then you know that something might be wrong with the SPI transfer routine.

     

    It wouldn't explain why this doesn't affect transfers to a 6581, but on such mysterious effects it's always a good idea to ensure the basic infrastructure first.

     

    Best Regards, Thorsten.

  12. Unfortunately there is no available target that will affect the pitch of all three oscillators. Is that correct?

    So the only way to do vibrato/pitch mod effects on all oscs is by selecting target 1-3 on the matrix, right?

     

    If you want to modulate all three pitches from a single modulation path, just enable the L/R switches of the direct modulation targets:

     

    mod2.gif

     

    These are the same switches which are displayed by the Matrix LEDs of the CS

     

    The "soft-targets" (Tr1 and Tr2) are only optional for the case that you want to control something else than Pitch, Pulsewidth, Filter or Volume.

     

    Best Regards, Thorsten.

  13. Not really - but remote diagnosis is difficult without knowing your hardware setup + software.

     

    The effect happened sporadically when a free-running (not synchronized) oscillator was used; conclusion:

    a) the SID clock shall be generated by the microcontroller

    b) each write access to a SID register shall be synchronized to the SID clock as described above to avoid timing violations.

     

    If the effect always happens, it could also be related to your hardware setup.

    E.g. defective SIDs, wrong voltage, wrong filter caps.

     

    Best Regards, Thorsten.

  14. The shift registers (to which the encoders are connected) are scanned each mS.

    Higher scan rates don't make a difference for encoders with up to 100 pulses per rotation.

     

    Here is btw. a tutorial for the encoder usage in MIOS32: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F014_enc_relative%2F

     

    And here is an older PIC ASM based solution, which might help you to understand the migration from ASM to C ;-)

    -> http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fmios%2Fmios_enc.inc

     

    Best Regards, Thorsten.

×
×
  • Create New...