-
Posts
15,247 -
Joined
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by TK.
-
-
Hi,
the code can be found here:
Best Regards, Thorsten.
-
Some devices have problems with the program change, I can't help here :-/
Best Regards, Thorsten.
-
->
Best Regards, Thorsten.
-
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 enableNow it always switches to the Jam page independent from record enable2) previously the position for step recording was independent from the position selected in the EDIT pageNow this position is the same to avoid inconsistencies3) EDIT page: previously special modes (like STEP RECORDING) where displayed at the place where normally the instrument is locatedNow the instrument/special mode display alternates (slowly)4) fixed „hanging notes“ issue in EDIT RECORDING functionTo 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.
-
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.
-
Hi,
no, this isn't supported yet.
In general pulses are not supported - only setting/resetting an output pin, but not triggering it for a certain time
Best Regards, Thorsten.
-
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.
-
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.
-
One of those quick changes that you shouldn't release w/o testing ;-)
It's fixed in pre17 (link changed in the posting above); thanks for the quick feedback! :)
Best Regards, Thorsten.
-
Hi,
there was never a "soldering guide", just only these pages:
http://www.ucapps.de/midibox_seq_v3.html
http://www.ucapps.de/midibox_seq_v3_options.html
Best Regards, Thorsten.
-
It's technically possible, but will require some complicated software extensions.
Actually I hope that ST will provide it together with the USB driver library, but it seems that it's even too complicated for those guys ;-)
Best Regards, Thorsten.
-
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.
-
Hi,
this was a temporary glitch which is fixed meanwhile.
E.g. in this pre-release:
Best Regards, Thorsten.
-
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.
-
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. -
I don't implement each "quick idea", only if there are very good reasons (and/or multiple people find it useful).
However, the new subsubpage has been added:
http://www.ucapps.de/mios32/midibox_seq_v4_088_pre15.zip
Best Regards, Thorsten.
-
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.
-
Alternatively: would it be acceptable to switch only between 14 patterns, and to use the 1st GP button to turn on/off the feature, and the 16th GP button to switch back to the original page view?
Best Regards, Thorsten.
-
Thanks for the feedback! :)
Since the same change is available in MIOS32, I guess that your station project will also benefit from this :-)
->
Best Regards, Thorsten.
-
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.
-
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.
-
An interesting hack! ;-)
But it won't work for receiving the values, and this would be a function which would require some firmware extensions (and consume some memory to make it generic)
Best Regards, Thorsten.
-
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.
-
Hi,
how do you process the events?
Are you calling a .NGR script section?
Best Regards, Thorsten.
MIDIbox SEQ V4 Release + Feedback
in MIDIbox SEQ
Posted
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. :)
This wasn't intended - should work with pre21
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.