Jump to content

TK.

Administrators
 View Profile  See their activity

  • Posts

    15,247

  • Joined

 Content Type 

Posts posted by TK.

  1. MIDIbox SEQ V4 Release + Feedback

    in MIDIbox SEQ

    Posted

    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.

  4. LPC17 DMX ?

    in MIOS programming (C)

    Posted

    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.

  5. Optimizing Encoder Behavior in MBSID Firmware

    in MIDIbox SID

    Posted

    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.

  7. Alternate "Synch to Measure" Idea

    in MIDIbox SEQ

    Posted

    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.

  8. Optimizing Encoder Behavior in MBSID Firmware

    in MIDIbox SID

    Posted

    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. Trigger Matrix & note processing

    in MIDIfication

    Posted

    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.

  14. Optimizing Encoder Behavior in MBSID Firmware

    in MIDIbox SID

    Posted

    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.

  15. Confusion about SID behavior

    in MIDIbox SID

    Posted

    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.

  18. MIDIbox NG V1.030 update issues

    in MIDIbox NG

    Posted

    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.

  21. MIDIbox NG V1.030 update issues

    in MIDIbox NG

    Posted

    The analog inputs dont send random midi events as if they are not connected. 

     

    Btw.: when you are writing AIN, do you mean the analog inputs of the MBHP_CORE_LPC17 module, or the analog inputs of the MBHP_MF_NG module?

     

    And with "not connected" you hopefully mean, that the unused analog inputs are connected to ground to avoid that a core generates random events (e.g. when you touch with your fingers over analog inputs...)

     

    When i move the fader up i ge a midi note with velocity 2 or 1 or 3 (just one) and when i move it down i get a note off.

     

    Do you mean the faders connected to a MBHP_CORE_LPC17 module, or to a MBHP_MF_NG module?

     

    How does your EVENT configuration for this fader look like?

    Background: I added some extensions for analog input processing, maybe you are using an incomplete configuration which selects an unintended mode?

     

     

    What do you say about the fc issue?

     

    I will probably add a feedback detection into the next firmware version which avoids this situation.

     

    But I guess that with the "MidiFileClkOutPorts" command you've a temporary solution which helps at your side, right?

     

    Best Regards, Thorsten.

  22. MIDIbox NG V1.030 update issues

    in MIDIbox NG

    Posted

    You are writing:

     

    ok when i start the Core with the MF_NG Modules Connected it falls into the "fc" loop. So i guess that is the issue...

     

    Previously you wrote:

     

    I unplugged the MF_NG Modules which doesnt made any cahnges.

     

    Does it mean that the previous observation was wrong, and that disconnecting the MBHP_MF_NG module makes a change?

     

    Best Regards, Thorsten.

  23. MIDIbox NG V1.030 update issues

    in MIDIbox NG

    Posted

    Just to ensure (because it seems that you are an lazy updater... ;-)) - are you using the latest MIOS Studio version?

     

    ok well it doesnt detect the core anymore but when i press a button this is send out by the core. And when i acces the files on the sd card this also works fine. Everything is a bit confusing...

     

    One explanation could be, that you haven't selected the *first* USB MIDI IN and the *first* USB MIDI OUT of the core module in MIOS Studio, but a mixed pair (e.g. first MIDI IN but second MIDI OUT... or similar).

     

    Another explanation could be, that you are working under Windows.

    In this case it's important that you are using MBNG V1.029 or higher (and the latest MIOS Studio version of course)

    Previous MBNG versions didn't contain the special Windows workaround for multiple USB MIDI Ports.

     

     

    The AINs are still not working properly. Is there a IC on the core that could be broken?

     

    Analog inputs are directly connected to the LPC1769, there is no IC between these connections.

     

    When you are writing that they are not working properly, does it mean that they are not working at all, or does it mean that unexpected AIN events are sent?

     

    Best Regards, Thorsten.

  24. MIDIbox NG V1.030 update issues

    in MIDIbox NG

    Posted

    What happens if you enter following command into the .ngc file:

    MidiFileClkOutPorts 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 

     

    Note that you could also enter it interactively into the MIOS Terminal with:

    ngc MidiFileClkOutPorts 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

     

    with 1.015

     

    If you've used v1.015 before, it doesn't surprise me that the motorfader control wasn't working correctly.

    A lot of changes have been added until then based on various user requests.

     

    Previous releases can be found under: http://www.ucapps.de/mios32/backup/

     

    However, let's focus on the MIDI Clock Stop Command issue - I think that I've to add something into the firmware which prevents such a situation.

    But I need to find out, what's special in your setup - therefore: than more observations that you could describe, than better.

     

    Best Regards, Thorsten.

  25. MIDIbox NG V1.030 update issues

    in MIDIbox NG

    Posted

    You are writing "0xfc continuously" - does it mean that there is a delay between each 0xfc (MIDI Clock Stop) event, e.g. 1..10...100 mS?

    Or is it sent without any delay?

     

    Compared to older versions, v1.030 got a MIDI Clock generator which would send 0xfc if it receives the same event from any MIDI IN port.

     

    So: which MIDI device could send 0xfc at your side?

    E.g. any device connected to a MIDI IN port, or maybe your DAW which sends to an USB IN, or could it be related to a feedback loop?

     

    Best Regards, Thorsten.

×
×
  • Create New...