Jump to content

TK.

Administrators
  • Posts

    15,199
  • Joined

Posts posted by TK.

  1. Btw.: please update the repository - yesterday I noticed that in MBNG the KEYBOARD_Periodic_1mS() function was running in the wrong task (background instead of APP_Tick())
    This could cause random velocity values if LCD messages are print as well.

    Best Regards, Thorsten.

     

  2. Can I ask the specs/datasheet of the LEDs you are using i.e. luminous intensity in mcd?

    see http://www.ebay.de/itm/171931571912

    R: 500-800mcd, G: 3000-5000mcd, B:2000-3000mcd

     you using current limiting resistors?

    220 Ohm for R+G, 100 Ohm for B

     What about RGB LEDs with embedded controller? WS2812B based RGB LEDs or LED strips are quite cheap on ebay.

    Hm! How could I overlook this! Actually I intended to try out this chip some months ago, but I totally forgot about this possibility! :)

    The SPI usage would be too expensive for this purpose, especially since most MBHP_CORE_* modules only have 3 integrated SPIs which are already assigned to other peripherals.

    But a 800bps rate (output only) can be easily achieved via bitbanging, e.g. if a DMA transfers the prepared pin access patterns triggered by a timer.
    I will try this soon, because it will be a much better solution for RGB LEDs!

    E.g. this seems to be a nice one: http://www.ebay.de/itm/1m-60-RGB-LED-Strip-schwarz-mit-WS2812B-5050-SMD-LEDs-WS2811-Controller-WS2812-/371332277097?hash=item567520e369

    Best Regards, Thorsten.

  3. Unfortunately you won't be able to detect a defect in the 74HC14 with an ohmmeter.

    The 74HC14 is an inverter chip, if input 6A is at logic-0 level (around 0V), 6Y should be logic-1 (around 5V) and vice versa. If this isn't the case, lift 6Y (pin 12) - means, put this pin out of the socket - and measure again. If you still don't notice the inverting function, then the chip is defective and needs to be replaced.

    Of course, overvoltage or wrong polarity could destroy this chip very quickly.

    The MBHP_BURNER project is maybe not the best one for beginners. Actually today (10 years later) I would recommend to buy a cheap PICkit2 (clone) at Ebay instead. See also http://www.ucapps.de/mios_bootstrap_experts.html

    So - if you are not able to get MBHP_BURNER running, consider to buy a PICkit2 at Ebay, it will be less troublesome.

    Best Regards, Thorsten.

  4. Please try this version:
    http://www.ucapps.de/mios32/midibox_ng_v1_033_pre16.zip

    The new command can be called with:

        exec_meta SaveDelayedSnapshot:15
    

    this will store the snapshot after at least 15 seconds (if there is no ongoing request)

    Currently it doesn't check if any value has been changed - this will become a difficult task at my side, but let's see if this command is already sufficient.

    Btw.: with "set debug on" in the MIOS terminal you will get a notification message whenever the snapshot save operation takes place.

    Best Regards, Thorsten.

  5. An event only takes place on a value change, but the problem is that with DumpSnapshot you provoke that all values will be sent out (again).

    Btw.: is it clear to you, that DumpSnapshot doesn't store values, but sends the values of all control elements?
    SaveSnapshot would be the right command for this purpose, but the problem is, that it store immediately with the effect that if the section is called rapidly multiple times per second (for whatever reason), the store operation will stall MBNG too much.

    I think the only proper solution for your use case would be a new NGR command which requests a snapshot save, and only if any value has been changed - it shouldn't take place more often than once per second, right?

    Best Regards, Thorsten.

     

  6. All that legato/sustain/note stretch features have been removed from the firmware (which is originated from MBSEQ V3) and no memory has been reserved to store such a parameter, therefore I don't see a way to consider your request.

    So, if you find a different solution (e.g. firmware change in 9090) it would be better.

    However, if you've luck following MB808 firmware change could already help:

    in src/seq_layer.inc, search for SEQ_LAYER_GetEvntL, it's currently:

    SEQ_LAYER_GetEvntL
            movlw   0x10                    ; fixed length
            movwf   SEQ_EVNTL, BANKED

    If you change it to:

    SEQ_LAYER_GetEvntL
            movlw   23                    ; fixed length
            movwf   SEQ_EVNTL, BANKED

    the note length should be almost 1/16th

    Higher values could result into legato, but I haven't tested this...

    Btw.: which firmware version are you using?
    V1.4 got some new features, e.g. a HH control switch for 909: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_808%2FCHANGELOG.txt

    But I noticed that I haven't officially released it yet; the mios_download page still shows v1.3

    Best Regards, Thorsten.

  7. The sammichFM is maybe a bad example, because the user interface doesn't allow to select the pages directly (like for example a MIDIBox SID (not sammichSID).

    However, it makes sense to collect opinions from future users.

    It should be possible to implement different CS approaches for the same hardware, just the frontpanel silkscreen will be different.

    Best Regards, Thorsten.

  8. Today I did some experiments with RGB LEDs, e.g. to evaluate Andy's idea to use a single RGB LED as replacement for LED rings around encoders: http://midibox.org/forums/topic/19619-alternative-to-led-encoder-rings-illuminated-red-green-encoders/

    Outcome:

    Conclusion: if LED rings should be replaced by RGB LEDs, we need 3 dedicated DOUT pins per LED, makes 48 pins for 16 RGB LEDs = 6 DOUT SRs
    Line drivers are not required, since the DOUT SRs are strong enough to drive the LEDs.

    Best Regards, Thorsten.

  9. Note your proposed encoder assignments do not include rate controls for the LFOs, A/D/S/R for the envelopes etc. -- how would you adjust these parameters?

    Whenever the LFOx or ENVx depth is changed, or the LFO1/LFO2/ENV1/ENV2 button is pushed, the appr. menu page will be selected which then allows to edit the remaining parameters.
    If somebody prefers to control a certain parameter directly, e.g. LFOx rate or ENVx decay, he has to change the encoder assignments.

    I think that at the end we might be able to use the same frontpanel, but labels need to be customized based on personal preferences.

    Best Regards, Thorsten.

  10. I think it will be simpler to identify modulators this way. I.e. Channel 1 LFOA = LFO1A, Channel 5 MOD C = MOD5C. Then the MOD is easy to assign across Channels.

    This kind of enumeration is legacy (e.g. same is used in MBSID and MBFM), please don't enforce a change (I won't do it anyhow ;-)

    Whenever a value is changed, the related CV1..8 channel + the parameter name is print on screen. No need to think about a different approach.

     Can you explain what you mean by this? I'm thinking about the following structure hierarchy, sorry if the pictures weren't clear:

    Choose a channel. Here on one page you can adjust all 8 modulators, activate the sequencer and apply velocity/aftertouch.
    Click "Config" and you have a second page of options.
    Bank+channel number will select each ENV, LFO, MOD and SEQ, some have two pages switched by Config such as the 16 steps of ENV2/B and SEQ. To me this is the most intuitive way to access all parameters of a modulator.

    this won't work in live situations, where you want to have immediate access to parameter splitted over different channels

    Your idea actually goes into a direction from where I wanted to get rid of.
    The purpose of the 4x4 encoder field shouldn't be to replicate that what can already be configured with the menu interface.
    Instead they should give you direct access to all parameters that you want to tweak live while playing sounds w/o switching banks or channels.

    I think a more flexible approach would allow 2, 4 or 8 voices. Especially in a modular setup the concept of 8 CVs is very powerful, going beyond just a MIDI to CV converter.

    Actually the firmware is constructed for 8 voices which work independent from each other.
    The idea is to customize the access to voice parameters in order to simplify the usage - the frontpanel design should consider this.
     

    ENC1-3: not required as there is a dedicated octave/fine encoder + a chromatic keyboard for semitone transpose

    ENC5-16: for the most flexibility I suggest all modulators of a channel are accessible on one "bank" 

    I think the biggest problem is, that you want to customize your MBCV for 8 voice usage and quick access to all configuration parameters.
    And that I'm looking for something different, tailored around my own use case.

    I fear that I've to create an alternative frontpanel design for my own usecase... :-/

     Is it not better to have all 16 steps on their own encoders?

    That's ok, but the second layer which allows to change SEQ configuration parameters isn't necessary.
    It's much easier to change these parameters from the menu interface, nobody will use the 4x4 encoder field for this purpose.

    Best Regards, Thorsten. 

  11. The MB808 firmware doesn't allow to configure the gate length of analog triggers, the pulse length is 1 mS for all outputs, and it won't be so easy to change with the existing code basis.

    I'm surprised that we haven't noticed this issue with the 808 modules, could it be that monoflops are missing for the drums which need to be played over long time?

    E.g. I found this blog via google: http://niroke.blogspot.de/2015/04/trigger-in-mod-for-tr-9090.html

    Are you using such a mod, or how did you connect the triggers?

    Best Regards, Thorsten.

  12. Please note: LFOA, LFOB, ENVA, ENVB, MODA..D are actually called LFO1, LFO2, ENV1, ENV2, MOD1..4, please change the graphics accordingly to avoid confusion.

    From my point of view, the encoder assignments are too much channel-related.

    I would prefer the configuration 2(VCO, VCA, VCF, MOD; Gate, Trig, Retrig, /Trig) with encoder assignments which change the most important parameters of an "instrument", such as:

    CV1: VCO1 Pitch
    CV2: VCA1 Amplitude
    CV3: VCF1 CutOff
    CV4: Aux1
    CV5: VCO2 Pitch
    CV6: VCA2 Amplitude
    CV7: VCF2 CutOff
    CV8: Aux2

    And the default encoder assignments could be:
    ENC1: CV1 Octave
    ENC2: CV1 Semitone
    ENC3: CV1 Finetune
    ENC4: CV1 Portamento
    ENC5: CV2 LFO1 Depth
    ENC6: CV2 LFO2 Depth
    ENC7: CV2 ENV1 Depth
    ENC8: CV2 ENV2 Depth
    ENC9: CV3 LFO1 Depth
    ENC10: CV3 LFO2 Depth
    ENC11: CV3 ENV1 Depth
    ENC12: CV3 ENV2 Depth
    ENC13: CV3 Value (Changes Octave/Semitone/Finetune)
    ENC14: CV4 Value (Changes Octave/Semitone/Finetune)
    ENC15: CV4 MOD1 Depth
    ENC16: CV4 MOD2 Depth

    I don't see the need to configure the MOD parameters with the 4x4 encoder matrix, it's much easier to change them from the appr. configuration page.

    Same for the ARP and SEQ configuration.

    Best Regards, Thorsten.

  13. The router settings should be automatically saved when you exit the page.

    E.g. just press the EXIT button or change to another page (EDIT button or whatever)

    It can be explicitly saved with the SAVE function in the main menu (GP button 10)

    Best Regards, Thorsten.

  14. Instead of

        if BUTTON:1001 == 0
            set LED:23 0
            set LED:22 0
            set LED:21 0
        else
            if BUTTON:1002 == 25
                set LED:23 127
                set LED:22 0
                set LED:21 0
            else
                if BUTTON:1003 == 51
                ...

    you could also write:

        if BUTTON:1001 == 0
            set LED:23 0
            set LED:22 0
            set LED:21 0
        elseif BUTTON:1002 == 25
            set LED:23 127
            set LED:22 0
            set LED:21 0
        elseif BUTTON:1003 == 51
        ...
        endif

    this results into a (little bit) faster handling, and is also easier to read & update

    The .NGR script will be executed in one go after the snapshot has been loaded.

    But if I do, I can hear a short interruption at my audio out about every second which tells me that this dump is being done repeatedly, interrupting the processor.

    I haven't mentioned it yet, but it could make sense to set the "no_dump=1" parameter for all events which get their value from other events via fwd_id

    This avoids unnecessary repetition.
    Note that after the modification you've to store the snapshot once in order to remove the unnecessary values. Thereafter a restore should work faster.

    Best Regards, Thorsten. 

  15. Please wait for this until I've checked various RGB LEDs at my side (it's on my Agenda to try this out for upcoming MBCV V2)
    I've already the RGB LEDs, just need some time for some experiments - and I will try this with a MBNG.

    It might be that I will add special extensions to minimize wiring effort, but to ensure that we've enough dim levels

    Best Regards, Thorsten.

  16. 50k and 1k are available in 10mm shaft. Might a good solution then be to order the 50k version then solder a 5k6 resistor in parallel to make about 5k?

    This won't work, because this way you will create a non-linear resistor network.
    There is no solution to turn a 50k fader into lower resistances, the high fader resistance is prone to jitter

    Best Regards, Thorsten. 

  17. Very well done! 

    Next up will be the LFO/Mod Bus/Noise Source circuit board on the hardware side and figuring out how to use a button to override a AINSER to AOUT value in order to mute a channel. No idea how this is being done. I guess it can be solved with SENDERs and RECEIVERs. In general, if someone knows how I can light an LED as well as set a separate DOUT pin with one button press, I would highly appreciate some help.

    Value forwarding can be disabled with a conditional event, e.g.:

    EVENT_CV id=1 if_equal LED:1:0 ...

    will only change CV:1 if the value of LED:1 is 0

    For driving a second DOUT you could forward in a chain:

    EVENT_BUTTON id=1 fwd_id=LED:1 ...
    EVENT_LED id=1 fwd_id=LED:2 ...
    EVENT_LED id=2 ...

    BUTTON:1 forwards to LED:1, and LED:1 forwards to LED:2

     

    But for the case that you would like to restore the original CV value if LED:2 changes back from any value to 0 (unmute), you finally need a .NGR script which is triggered by an EVENT_SENDER:

    EVENT_BUTTON id=1 fwd_id=LED:1 ...
    EVENT_LED id=1 fwd_id=SENDER:1 ...
    EVENT_SENDER id=1 type=Meta meta=RunSection:1

    And in the .NGR script something like:

    if ^section == 1
       if BUTTON:1 == 0
          # button depressed: unmute
          set LED:2 0
          # copy current AINSER:1 value to CV:1
          set CV:1 AINSER:1
       else
          # button pressed: mute
          set LED:2 127
          # mute CV output
          set CV:1 0
       endif
    endif
    

    Best Regards, Thorsten.

×
×
  • Create New...