Jump to content

TK.

Administrators
  • Posts

    15,198
  • Joined

Posts posted by TK.

  1. Hi Lars,

     

    it would be very difficult (and the wrong way) to implement additional encoder functions for GPIOs.

    They consume more CPU time than scanning the SRIOs (might sound strange, but the standard scan via SPI in background results into a better overall-performance)

     

    Only possibility that I see is to explain you how to modify the firmware for your particular use case.

    But I don't really want to provide a generic (user-configurable) solution.

     

    Alternatively buy a 74HC165 @Reichelt for 0.30 EUR...

     

    Best Regards, Thorsten.

  2. It still works at my side, but I noticed a problem with the "store" function - it doesn't store the network setup.

    Could this be the problem at your side? (check the current configuration with the "network" command)

     

    The fix will be available with the next release.

    Meanwhile you could enter the configuration directly into the MBSEQ_GC.V4 file:

     

    BLM_SCALAR_Port 66
    

    and

    OSC_RemoteIp 2 192.168.11.102
    OSC_RemotePort 2 8000
    OSC_LocalPort 2 8000
    OSC_TransferMode 2 1

    (note that in this file the connection numbers are counted from 0)

     

    After the changes, enter "reset" to reload the configuration.

     

    Best Regards, Thorsten.

  3. To 1)

     

    in src/cs_menu_tables.inc you will find following table:

     ==========================================================================
    ;  The wavetable menu
    ; ==========================================================================
    CS_MENU_TABLE_WT
        db  (CS_MENU_TABLE_WT_End-CS_MENU_TABLE_WT)/CS_MENU_ENTRY_LEN, 0x00
    
        ;;              Register (00=dummy)        |<-->|  max   print ix,         exec ix          parameter transfer
        CS_MENU_ENTRY   CS_MENU_WT_STEP,           "Step", 0x1f+1,PRINT_VAR_WTSTEP, EXEC_SELPAR,     R2PP2R_VAR_WTSTEP
        CS_MENU_ENTRY   0x00,                      "Mode", 0x03, PRINT_VAR_WTMODE, EXEC_TOGPAR,     R2PP2R_VAR_WTPAR
        CS_MENU_ENTRY   0x01,                      " #1 ", 0xff, PRINT_VAR_WTPAR,  EXEC_SELPAR,     R2PP2R_VAR_WTPAR
        CS_MENU_ENTRY   0x02,                      " #2 ", 0xff, PRINT_VAR_WTPAR,  EXEC_SELPAR,     R2PP2R_VAR_WTPAR
        CS_MENU_ENTRY   0x03,                      " #3 ", 0xff, PRINT_VAR_WTPAR,  EXEC_SELPAR,     R2PP2R_VAR_WTPAR
        CS_MENU_ENTRY   MBFM_Px_WT_RATE,           "Rate", 0x7f, PRINT_Px_DEC,     EXEC_SELPAR,     R2PP2R_Px
        CS_MENU_ENTRY   MBFM_Px_CTRL2_U,           "Sync", 0x02, PRINT_Px_WTSYNC,  EXEC_TOGPAR,     R2PP2R_Px
        CS_MENU_ENTRY   MBFM_Px_WT_PAR1,           "CC#1", 0x7f, PRINT_Px_CCASG,   EXEC_SELPAR_ASG, R2PP2R_Px
        CS_MENU_ENTRY   MBFM_Px_WT_PAR2,           "CC#2", 0x7f, PRINT_Px_CCASG,   EXEC_SELPAR_ASG, R2PP2R_Px
        CS_MENU_ENTRY   MBFM_Px_WT_PAR3,           "CC#3", 0x7f, PRINT_Px_CCASG,   EXEC_SELPAR_ASG, R2PP2R_Px
    CS_MENU_TABLE_WT_End

    Here you could re-order the menu items to test if you are satisfied with the result.

    Once you are happy, and for the case that more people would like to get this change, I would change this in the official firmware

     

     

    To 2) I understand your wish (I had the same, and implemented in MBSID V2)

    But for MBFM it isn't possible due to memory limitations and design decisions which make it difficult today to add such changes, as simple they might sound for you as a user...

     

    Please note also, that the MBFM project is only in "maintenance mode" anymore, which means: only bugfixes and minor changes which don't need much attention from my side will be provided.

     

    Best Regards, Thorsten.

  4. The usage of source drivers (the transistors) is for pro users who want to get perfect results.

    I'm unsure if this really makes a big difference.

    It's more important that you try to keep the number of selection lines per matrix as low as possible (8 is acceptable, 4 is perfect)

     

    Best Regards, Thorsten.

  5. Would it be possible to get a config param that would when in Force To Scale mode, show the actual note that the sequencer has been quantized to? I can see how this would be tricky and not the expected behavior in some situations. So an option would be nice, but I can see how this would be a lot of work.

     

    In this version the quantized value should be displayed at the lower line. The unquantized value is still visible at the upper right line.

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

     

    This approach isn't an option, but always applied.

    Could you please test this at your side?

     

    Best Regards, Thorsten.

  6. That's too much code for a quick check (and I'm also no DMX expert...)

     

    However, you wanted to setup Push Pull mode, but actually you activate Open Drain Mode:

       MIOS32_SYS_LPC_PINMODE_OD(2, 0, 1);

     

    Write (2, 0, 0) instead to ensure that Push-Pull is configured.

    (Sidenote: due to a LPC1769 silicon bug, it will be push pull anyhow, but just to ensure...)

     

    For the baudrate and pin behaviour, I'm sure that the scope will help to debug this! :)

     

    Best Regards, Thorsten.

  7. So you changed it by altering mios8 if i understand correctly. Will this have an effect (positive or negative) on other applications, like MB64e?

     

    Yes, it should have a positive effect on a MB64E as well.

     

     

    i just did a quick test for now as i am off for work. I am not quite sure if i notice a difference. Was it a big change on your setup or rather subtile?

     

    For large value ranges it's only subtile, for smaller ranges (e.g. 0..255 - mostly used) it's noticeable.

     

     

     My test is trying to set cutoff to 800, i most often get jumps like 76f to 830 with just 3 ticks of the encoder unless i turn very slowly.

     

    This doesn't happen at my side.

    Ok, it depends on how we define "very slowly..." - but when I rotate the encoder slowly I can see that the values are incremented continuously and precisely +/- 1

    With MIOS V1.9g sometimes the value was sporadically incremented much faster on slow movements, but with MIOS V1.9h this doesn't happen anymore.

     

    It could be related to your encoder.

    How does it work when you are changing CutOff with the main encoder instead?

     

    And compare also parameters with lower value ranges, acceleration control should be super-precise for them now :smile:

     

    Slave cores don't need the MIOS V1.9h update.

     

    Best Regards, Thorsten.

  8. Hi Phill,

     

    I thought that this would be a way to "quantise" the dividing and un-dividing the clock of a track, so that they don't get out of sync with the main  "global"  tempo

     

    no, it "quantise" to the measure instead, and the measure length can be configured in the Utility->Opt page (it's 16 steps by default)

     

    Whenever these number of steps have been played, the step progression (clock divider values and step position) of the tracks which activated this synchronisation option will be reset.

     

     

    I start with all tracks playing 16 steps at a divider of 8...

    I then decide to half the tempo divider on 4 on one track

    (currently this leaves it possibly out of time compared to the other tracks unless I go to the Manual Steps page and  re-align which has the downside of not being instant)

     

    All tracks which have enabled the sync option should be aligned again once the measure has been played.

    I just tested this again at my side: it still works. :smile:

     

     

    what I was expecting with sync to measure" is that my request to divide or multiply the clock would be "parked" as a command until the next time we came to step 1 on the sequencer. Thus keeping all tracks aligned even when running at a different clock speed.

     

    This would be a slightly different approach, and I'm not sure if this is better than the current one.

    Currently the tracks just continue to play until the 1st step of the measure is reached, then all tracks which have this synch option enabled will be restarted and are then aligned again.

     

     

    On a related, but separate note, I have noticed that inputting using the Live Record method on an empty track that has been divided during the performance seems to mean that even if I play exactly ON the beat (ie 1, 5,9,13 etc) when the sequence loops round, my input notes are shifted to a new position within the track ( quantize is at 50% btw)...

     

    The quantization works depending on the clock divider, and this might confuse you.

    Means: with a clock divider of 16 (16th notes) one step takes 96 "clock ticks". With a quantisation of 50% the incoming MIDI event will be put into the next step if it's delayed by more than 48 ticks.

     

    With a clock divider of 64 (4th notes) one step takes 384 ticks, therefore the incoming MIDI event will be put into the next step after a delay of 192 ticks.

    So: the time window over which the quantisation takes place is much larger.

     

    However, I think that 50% is a bad choice anyhow.

    Most people prefer 10%

    We had 20% by default some time ago, but users complained that this is too much.

    Therefore I would propose to try smaller values.

     

    Best Regards, Thorsten.

  9. Ok, starting with MIOS32 was a good idea, because especially the possibility to send "printf" like debug messages helped me to find an easy solution, which also fits nicely into MIOS8.

     

    Could you please install this new MIOS version: /edit: removed expired link, please download the official version under http://www.ucapps.de/mios_download.html

     

    Thereafter install MBSID V2 again: /edit: removed expired link, please download the official version under http://www.ucapps.de/mios_download.html

     

    (still enctest2, the same that I provided some days ago)

    Encoders should behave better now!

     

    Best Regards, Thorsten.

  10. I understand your requests, but from my point of view they don't fit with the concepts behind MIDIbox CV.

    It would be a separate application with a dedicated UI.

    If you don't mind, I will split your post to a separate topic - maybe somebody else with programming skills is interested to help you...

     

    Best Regards, Thorsten.

  11. It seems to me that the transission between slow and accelerated speed is quite low. When an encoder is turned slowly the increments are smooth and slow. Go just a little faster (but still quite slowly) the threshold is reached and speed is accelerated. If this threshold would come in a bit later that would feel much better.

     

    I know what you mean, because I had the same impression and see the need for improvements.

    But it won't be trivial, especially since a (more than 10 years old) routine in MIOS8 has to be overworked, and this will be *very* time consuming.

     

    However, meanwhile I got the idea that I could try to improve this in MIOS32 first, which has the same algorithm. And once I'm happy, I could translate it into the (assembly based) MIOS8.

    Hopefully it will be possible without consuming additional RAM, because there is no free RAM available in MIOS8...

     

    Best Regards, Thorsten.

  12. A SID player can switch between multiple patches quickly (almost zero-time) because it has direct access to the "patch memory".

     

    MIDIbox SID has to load patches from an external EEPROM instead, this consumes time and the amount of time depends on the patch size.

    During the development phase of the firmware (ca. 7 years ago) the first beta users preferred to get as many sound features as possible. This was leading to an increased patch size, and this was in contradiction to the patch load speed, but it has been accepted.

     

    So, somebody could implement an alternative firmware with much less sound features, but faster patch load time.

    Or somebody could use a more modern microcontroller with enough embedded RAM (or fast access to external memory) to overcome such limitations.

     

    It wouldn't be in my own scope, because I'm happy with the implementation.

     

    Best Regards, Thorsten.

  13. The changed behaviour in V1.030 is related to the new Switch function, which ensures that a NoteOn/Off event is only sent once as requested here: 

     

    So, you have a different use case which I haven't considered: you want to send continuous Note On events from an analog input like somebody is normally doing with CCs, right?

     

    Here a modified version which disables the change for "AIN Switches", so that you can proceed with the analysis:

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

     

    Unfortunately this won't satisfy the needs of dOperator anymore... :-(

    In future it will be required to enhance the EVENT_AIN configuration in order to select one of the contradicting use cases.

     

     

    I did another change in this version: "MIDI Clock Inputs" are disabled by default now.

    Could you please check if the "MidiFileClkOutPorts" workaround is still required at your side?

     

    Best Regards, Thorsten.

×
×
  • Create New...