Jump to content

TK.

Administrators
  • Posts

    15,247
  • Joined

Posts posted by TK.

  1. Regarding the quantisation, I think it's ok if it's known/documented in the manual as it is.

     

    Alright, I will document this at the http://www.ucapps.de/midibox_seq_manual_ki.html page (which is currently empty ;-)

     

    Sooner or later I will revise the code based on the features which have been integrated in the last months. Currently there is a lot of cumbersome "experimental" code which I added quick&dirty for evaluation purposes. Once I'm sure that the feature set is settled, it makes sense to think about a proper solution. :)

     

     

    However, when you now use EDIT RECORDING, you can only record notes with length 1%, so you have to adjust the length by hand if you want to hear what you recorded. When you're recording a step, as long as you hold the key(s) down, the right LCD upper row shows "length 75%", but when you release, it changes to 1%.

     

    This wasn't intended - should work with pre21

     

     

    One more this that I found today, maybe it's intentional, but I thought I'd mention it: If you have set the Parameter Layer C button functioning to 'toggle' in the HW setup file, you can get into the following situation.

     

    This option hasn't been considered, it should be fixed as well

     

    Please try: http://www.ucapps.de/mios32/midibox_seq_v4_088_pre21.zip

     

    Best Regards, Thorsten.

  2. Thanks for the valuable feedback! :smile:

    Here a new version: http://www.ucapps.de/mios32/midibox_seq_v4_088_pre20.zip

     

    I did following changes:

    1) previously the record button switched between Edit/Jam page depending on recording enable
    Now it always switches to the Jam page independent from record enable
     
    2) previously the position for step recording was independent from the position selected in the EDIT page
    Now this position is the same to avoid inconsistencies
     
    3) EDIT page: previously special modes (like STEP RECORDING) where displayed at the place where normally the instrument is located
    Now the instrument/special mode display alternates (slowly)
     
    4) fixed „hanging notes“ issue in EDIT RECORDING function
     
     
    To answer your questions & requests:

     

    some feedback. I have set Rec 'on' in the Jam page, then pressed EDIT to start entering notes, with step+1 (though the step setting could be anything). I enter a few notes and then find I pressed the wrong key for a few steps. As it is, I cannot use the datawheel to change the position and start entering new notes from the new location, because the seq always takes the "current" location from the Jam page. So if the last note I entered is in step 10, and then use the datawheel to move to e.g. step 2 and press a key to record a note, the seq jumps to step 11 instead and records the note there. If you want to go back to an earlier location, you must do it via the Jam screen knob 11.

     

    should be fixed with 2)

    Please check if this causes new (unintended) side effects

     

     

    Is it possible and a good idea that the "current" location can in this situation be set also with the datawheel, and not only with knob 11 in the Jam screen?

     

    Would be inconsistent...

    But: once you controlled the step position with Knob 11, you can use the datawheel to change the value as well. With change 2) it should have direct influence on the edit position so that there is hopefully less confusion about the cursor...

     

     

    BTW if you first set Rec 'on' and then press EDIT, and then press SELECT, the seq switches between "step recording" and "edit recording" (or the text on the screen does). Are these two different functions, or is it only the text that is changing?

     

    Actually EDIT recording is the same like STEP recording with the difference, that it would also be STEP recording if no recording, or live recording is enabled.

     

     

    EDIT: Oh and the newest update section in changelog (and the last entry of that section) still mentions Record page by e.g. giving the advice to press Utility->Rec->Ptn, when the Rec is actually Jam now. Maybe that should be changed?

     

    changed now

     

     

    Also I had one of my Function buttons on the CS wired for "BUTTON_RECORD M2 2", but it didn't work properly anymore with the new Jam page. It does take me to the Jam page when Rec is 'off', but doesn't when it's 'on' (when it's 'on' it takes me to EDIT page from anywhere).

     

    fixed with 1)

     

     

    one more thing (Columbo style :-)  In the case described in my previous message (#893), where I set Rec to 'on' and then go to EDIT page, the top row of the left LCD reads "STEP RECORDING", and it covers the name of the track (the situation was more or less the same with earlier versions, if I recall right, so it wasn't introduced with the Jam updates).

     

    changed with 3)

     

     

    Then the following setup: On the Jam page, Rec is 'off', Forwarding is 'on' and Mode is 'Poly', and I use the Edit page Select button to start recording. If I record a note (or chord) in a step, everything is ok. But if I first record one note/chord, and thenanother, different note (or chord with at least one different note than in the first) in the same step, then the "different" notes (the notes that are in the first chord but not the second) will start playing, and won't stop. I've tried this with single notes and three-note chords, I don't know what happens if free note layers run out (I have 5 note layers in the track).

     

    hopefully fixed with 4)

     

     

    From Stuartm (confirmed by Jjonas):

    I did a lot of jamming and recording yesterday night, and came across a similar issue when recording to an 8-layer drum track part by part (i.e. first the claps, the hi hats, then snare etc.)

    While in live recording, whenever I hit a note on a step that already contained some triggers it sounded as if only the live played note was sounding, and the triggers already in the track are silenced.

    They were recorded alright and everything was fine once I stopped tapping in notes.

     

    Example:

    Record a clap to beats 2 and 4.

    Tap a 8th note hi hat pattern. While tapping this in, the claps on the 2 and 4 are not sounding.

    Stop tapping, both clap and hihat are sounding.

     

    We've a general issue here with the way how MBSEQ handles the quantisation.

     

    If the quantisation threshold is reached, MBSEQ puts the note into the next step, and then mutes the entire step so that it won't be played twice.

    For drum tracks I would have to differentiate between the recorded layers, and existing layers - this requires an extension.

     

    The same mechanism also causes a problem if a long note is recorded as mentioned by Jjonas.

    Since the quantisation can't look into the future, it doesn't know if the note will be played for more than one step, and therefore just stops it to avoid hanging notes.

     

    I've to spend some thoughts about how to solve both problems, but it will take some time and since the changes are criticial (-> error prone) they won't be part of the upcoming release.

     

    Best Regards, Thorsten.

  3. Live Patterns are now stored/restored in the local (session specific) MBSEQ_C.V4 file with following format:

     

    LivePattern  1  o...............
    LivePattern  2  o.......o.......
    LivePattern  3  ....o.......o...
    LivePattern  4  o...o...o...o...
    LivePattern  5  *...o...*...o...
    LivePattern  6  ..o...o...o...o.
    LivePattern  7  ..*...o...*...o.
    LivePattern  8  o.o.o.o.o.o.o.o.
    LivePattern  9  *.o.o.o.*.o.o.o.
    LivePattern 10  .o.o.o.o.o.o.o.o
    LivePattern 11  .*.o.*.o.*.o.*.o
    LivePattern 12  oooooooooooooooo
    LivePattern 13  *ooooooooooooooo
    LivePattern 14  *ooooooo*ooooooo
    LivePattern 15  *ooo*ooo*ooo*ooo
    LivePattern 16  ooooo*ooooooo*oo
    

    And the "recording" page has been renamed to Jam.

     

    Please help to test this release candidate (no additional features planned for this version):

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

     

    Best Regards, Thorsten.

  4. Danke fuer den Hinweis, der Fehler ist gefixt.

     

    Ich habe auch mal (auf die schnelle) das MacOS Build Script angepasst, so dass sich die Applikation kompilieren laesst.

    Leider crasht es schon sehr frueh - evtl. wegen eines Kompatibilitaetproblems mit PYMIDI - es wird aufwendig das zu debuggen, deshalb lass ich es erstmal wieder sein.

    Die Emulation ist mit der Maus sowieso sehr umstaendlich zu bedienen. Es gibt zwar noch eine iPad Variante, doch hier ist das Display zu klein und das MIDI Timing ist sehr unstabil - deshalb habe ich das nie veroeffentlicht.

     

    Die Juce-Anpassung ist nicht trivial - lassen wir das Thema ;-)

     

    Gruss, Thorsten.

  5. It was counted from the start, and then repeated each Nth bar.

     

    I see the benefit, and the most simple way to satisfy both is just to separate between Nth1 and Nth2 behaviour.

    Try this version: http://www.ucapps.de/mios32/midibox_seq_v4_088_pre18.zip

     

       o added new parameter layers "Nth1" and "Nth2" which trigger a special action 
         on each nth bar (Nth1) starting at the 1st bar, or after nth bars (Nth2).

     

    Best Regards, Thorsten.

  6. Ja, auf dem Subversion Server liegt eine Version fuer MacOS, die ich jedoch schon lange nicht mehr gepflegt habe.

    Ich muesste das Projekt auf die neusten Xcode Version portieren, und ein paar .c files, die mittlerweile hinzugekommen sind, einbinden.

     

    Arbeitest Du unter MacOS?

    (es gibt weder eine Anpassung an Windows, noch an Linux...! Das muesste man grundsaetzlich anders angehen, bspw. basierend auf Juce)

     

    Gruss, Thorsten.

  7. Yes, can be created very easily with a parameter layer assigned to Roll2, no need to use another track.

    Search for "Roll2" here: http://www.ucapps.de/midibox_seq_manual_m.html

     

    There is an open request in the wishlist which would allow similar effects:

    ----------------------------------------------------------
    Trigger steps from another track:
    
    ----------------------------------------------------------
    

    but it isn't implemented yet

     

    Best Regards, Thorsten.

  8. I implemented the "Nth" mode today - have fun!
    -> http://www.ucapps.de/mios32/midibox_seq_v4_088_pre17.zip
     

       o added new parameter layer "Nth" which triggers a special action on each nth bar.
         Following trigger conditions are available:
         - Pl (Play each nth bar)
         - Mu (Mute each nth bar)
         - Ac (Accent each nth bar)
         - Ro (Roll each nth bar)
         - Fx (enable Fx each nth bar)
         - Nx (don't enable Fx each nth bar)
    

     
    Unfortunately "Skip", explicit "Random" and explicit "Echo" isn't possible with the way how the core engine is implemented, therefore I renamed these modes to "Fx" and "No Fx"
     
     
    This is a release candidate for V4.088
    Major update is in the Record and Live screen.
    The new live patterns won't be stored yet - I will add this soon and then officially release V4.088
     
    New features won't be added to V4.088 anymore (I would like to get this stable after considering so many requests...)
     
     

    At the moment in the Length screen, if you have two notes and the first one has a length of 91%, you can see that there is a visible gap between the length bars of first note and the second note. If you increase the length of the first note to 92 %, there is no glide of course, but the visible gap disappears, and the length bar looks the same as if the length was 100%. I would find it useful if the gap appeared immediately when you adjust down from 100% (glide) to 98% (no glide) instead of the gap appearing only at 91%.

     
    Should work as requested with v4_088_pre17
     
    Best Regards, Thorsten.

  9. Especially if this feature (which should be commonly supported by all MIDI devices) is explicitly mentioned in the user manual it could be related to a problem in earlier firmware versions... ;-)

     

    Best Regards, Thorsten.

  10. Hm... it's too long ago where I worked on this code (9 years ago!)

     

    Could you please check if the NRPN based value change will be displayed on the LCD in the corresponding page?

    Then I've a simple explanation: the value will be written into the edit buffer, but won't be transferred into the shadow buffer which is used by the sound engine

     

    Accordingly, it would be required to copy the value into the edit and shadow buffer (and not only in one of these buffers).

     

    Best Regards, Thorsten.

  11. Hi,

     

    no further information required - it's a known limitation of the .NGR approach, and there is no workaround.

     

    However, you are now the second guy who describes a use case which requires an improvement.

    See also: 

     

    So, more likely I will work on a solution - anytime soon ;)

     

    Best Regards, Thorsten.

  12. Well, by changing SID_PATCH_BUFFER_SHADOW to SID_PATCH_BUFFER (at many places in sid_parin.inc and sid_parout.inc) values would be written (and read from) edit buffer instead of the shadow buffer, but this will also result into destructive write operations from the WT sequencer and some other functions.

     

    Best Regards, Thorsten.

×
×
  • Create New...