TK.
-
Posts
15,247 -
Joined
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by TK.
-
-
1. press and hold "copy" button
2. press paste button
3. pattern length is doubled along with all layer informations
ok, this is easy ;-)
Added to the wishlist
--> are there any news on that proposal? because i find myself quite often using the euclid-function and i always think "hmmmm, i want to select note/note layers the euclid population will be directed to"No, but since there is no better idea yet, I finally added it to the wishlist
Euclid generator: allow to select the note layer into which the pattern will be copied
---> this one moved up and up on my list. what do you think about that extension of an already existing "killer feature" which is the save&take over patterns functionok, added to the wishlist as well so that it doesn't get lost
Best Regards, Thorsten.
-
No, currently this isn't possible
Best Regards, Thorsten.
-
Hi Jasper,
no, unfortunately this isn't possible because of the way how MBSEQ stores MIDI events.
It would require a different concept to store the data (like on a pianoroll known from DAWs) with the disadvantage that some step based features wouldn't work anymore.
Best Regards, Thorsten.
-
Hallo Andre,
Du verwendest ein graphisches Display, richtig?
Dann dauert die LCD Ausgabe zu lange.
Abhilfe: die Zeichen in einem RAM Buffer zwischenspeichern, und im LCD Handler ausgeben.
Hier hat man dann die Zeit, die fuer die Display-Ausgabe spendiert wird, besser unter Kontrolle.
Ich weiss jetzt nicht auswendig, wie lange die Ausgabe bei GLCDs dauert (das haengt vom Display-Typ ab), doch der PIC sollte nicht mehr wie 10 mS spendieren, ansonsten laeuft der MIDI IN Buffer ueber (der kann in dieser Zeit ca. 30 Bytes empfangen)
Die LCD Ausgabe sollte also so aussehen, dass der LCD Handler im RAM Buffer nach neuen Zeichen sucht, sie ausgibt, und nach (bspw.) 10 Zeichen abbricht.
Wenn er erneut aufgerufen wird, kann er die restlichen Zeichen abarbeiten, bis der Display-Content mit dem RAM Buffer uebereinstimmt.
Wie erkennt man neue Zeichen?
Am einfachsten, in dem man im Buffer die bereits ausgegebenen Zeichen auf 0 setzt, oder auch einfach bit #7 setzt (so mache ich das ueblicherweise - Vorteil: die Zeichen gehen nicht verloren, man koennte also bspw. temporaer auch etwas anderes auf dem Display darstellen, und dann zurueck zum gebufferten Screen)
Gruss, Thorsten.
-
too bad that this wasn't the reason - it was the last hope that such a minor issue could be the reason.
ah, I see.... a relative-vs-absolute thing?No, this comparison is important for the case that somebody wants to record parameter changes with an external DAW. The MBSEQ UI will only send actual changes via CC to simplify editing of the recorded data.
if I had a wishlist, a more flexible configuration of the mixer pages would be quite a bit higher up....Mixer page extensions are expensive (resource & conceptional effort wise) and have to be prioritized with other items in the wish list.
I won't work on major features extensions in the next 2..3 months, so don't try to request everything which comes into you mind, instead please start exploring the given possibilities first and try to consolidate your ideas so that they fit into the given framework (and into the $10 chip of the core module which sets the limits as well ;-))
Best Regards, Thorsten.
-
Finally a stable design for jam sessions so that I can put the prototype into the MIDIbox museum - thanks for the great work!!! :thumbsup:
Name PCB BLM PCB miniCore Case Shift button M2 hardware 4xLED availability 5 5 - 9 6 17 latigid on 1 1 1 1 1 1 Rowan 1 1 1 1 1 1 Phatline 2 2 1 1 1 1 TK 1 1 1 1 1 1 Total 5 5 4 4 4 4
Best Regards, Thorsten.
-
This makes sense (actually I miss this possibility as well! :-))
Added to the wishlist
Best Regards, Thorsten.
-
I cleared both patterns & built new ones in their place, still the same thing.
I think that I found the issue:
Track 1 has Octave Transpose +0
Track 2 has Octave Transpose -1
If both tracks are selected and the configuration of Track 1 is visible, Transpose +0 has no effect
If both tracks are selected and the configuration of Track 2 is visible, Transpose -1 has no effect
Because the global parameter handling function breaks if the changed value is equal to the visible value.So, if you would select +1 instead after power-on, the change takes place, and that's the reason why I haven't noticed this. ;-)Please try this update:Change should take place independent from the visible value now (for all parameters, not only transpose)Best Regards, Thorsten. -
Has the PIC been bad flashed at some point - I remember having a bit of a nightmare getting it to flash 3 years ago and only succeeded in Linux in the end.
Yes, this could explain the behaviour (and based on that what I see on the video, I can say that this isn't normal)
Please try it with a proper MIOS and MBSID installation:
- power-off the sammichSID
- load the mios_v1_9h/pic18f4685/midi/mios8_v1_9h_pic18f4685.hex file
- press the Start button
- now power-on the core
-> upload should be finished within ca. 10 seconds
After MIOS has been installed successfully, the MIDIbox SID application can be uploaded without this special trick.
Btw.: is your MIDI interface on the blacklist? -> http://www.midibox.org/dokuwiki/doku.php?id=midi_interface_blacklist
Best Regards, Thorsten.
-
I'm wondering if the transpose thing is because one of the two tracks was created in jam mode....
No; the notes which are visible on the screen will be transposed, just straightforward without special dependencies.
And the firmware uses the standard function to change octave/semitone transpose values, the function itself takes care for multi-track selections.
Which means: if you notice such a problem in the transpose page, you would notice the same in most other pages where the standard function is used.
it's still exhibiting this behaviour despite changing the jam track to T&A though...Could you please explain a bit further what you mean with this?
It would really be helpful if you could explain the steps which are required to reproduce the problem, such as:
- power-on
- MENU+GP7 (Transpose)
- Push&Hold Track1, Push Track2: both tracks should be selected
- press GP10 to change Octave Transpose from +0 to +1
I tried the "TUTOR2" session that you gave me, but without success - meanwhile I assume that we are speaking about different pages.
the roll thing.... what I mean is, use the parameter layer roll settings to set the number of repeats & their spacing, & the trigger layer to switch them on & off. this way, you can preset the roll vallues you want against each/all of the steps, then enable/disable the rolls using the trigger layer. otherwise, when you want a roll, you have to scroll through the values to get to the one you want, & the sequence will play one or two incorrect rolls while you are doing this.Ok, this is an easy enhancement and it's also no critical change, since people who want to use the function have to reconfigure track assignments (so: they have to know what they are doing) -> no compatibility issues to be solved.
Try this version: http://www.ucapps.de/mios32/midibox_seq_v4_089_pre2.zip
Change to the Menu+GP9 (Trigger) page, disable the Roll trigger assignment (normally C), and assign RollGate (displayed as "RollG" under GP10) to C
-> rolls will only be played if the RollGate is set, and the Roll or Roll2 parameter layer doesn't show "----" for the step.
Best Regards, Thorsten.
-
I'm trying to transpose tracks 1 & 2 together. as I said, the display tells me I have multiple tracks selected for editing, but only the one I was in when I selected the other one gets transposed. so if I have been editing in track 1, then change to track 2, then hold down track 2's button & select track 1, the display changes but only track 2 gets transposed.
Both tracks get transposed at my side, regardless in which order the tracks have been selected.
Just to be sure: can you transpose the first track when only this one is selected?
Could you please pack your session subdirectory into a .zip file and attach it to this thread?
Best Regards, Thorsten.
-
It was just an assumption...
I don't know (and I'm too lazy to install Ubuntu14 in order to check your source files there)
Let's see if anybody else has an idea what could cause the warnings that seem to worry you.Best Regards, Thorsten.
-
I'm planning to implement some kind of compiler, which translates the .ngr commands into opcodes stored in RAM and executed dramatically faster than today.
So, if performance is the only issue, it will be solved sooner or later (but not in the next two months)
Best Regards, Thorsten.
-
The simple bank mechanism won't help you to achieve this.
Instead, you've to activate/deactivate the events from a run script: http://www.ucapps.de/midibox_ng_manual_ngr.html
with the "set_active" command
This approach can result into a long list of commands, but it's the most flexible solution...
Best Regards, Thorsten.
-
It wouldn't surprise me if you are getting warnings when you are using a different gcc version.
Even more dangerous are the hidden differences which are only visible by running the code and could result into a lot of trouble!
Therefore I strongly recommend you to use the official MIOS32 toolchain which is located under: http://midibox.org/mios32_toolchain/
All other versions are unreliable.
Best Regards, Thorsten.
-
The USB descriptors of MIOS32 match with the descriptors of the official usbmidi interface spec, no special tricks have been used, and Windows/Linux/MacOS are happy with them.
So, if another Host doesn't connect, it's an imperfection in the Host driver and you've to report this to the appr. manufacturer, not me!
In any case it always makes sense to check, if the manufacturer already fixed the bug in a newer driver version based on customer feedback...
Best Regards, Thorsten.
-
whenever you want to print floats with %d, you've to cast the appr. variable to integer with (int)variable, e.g. (int)value
Best Regards, Thorsten.
-
Just since the diagram doesnt say, and USB works so I figure its no problem ... but what are the 4 close connections under the USB, and should they be completely isolated?
This is 5V, Ground, D+ and D- (protocol lines)
If 5V isn't properly connected to the appr. USB pin, then a similar effect could happen as well; core will be supplied via D+ in this case, but it's only a "weak" power path.
So: check especially the USB pin connected via J17 jumper to 5V!
Best Regards, Thorsten.
-
The slow power ramp-up is very unusual, actually the 3.3V should be available immediately (less than 1 second) - of course, this is the answer for strange firmware effects, but a firmware change won't help to fix this problem!
The rectifier can't cause such an effect, it's more likely a problem with your external PSU.
Could you please try a different USB hub?
Or alternatively power the core directly from a 7..10V PSU via J1 (remove the J17 jumper for this option)
Best Regards, Thorsten.
-
I need your configuration files to reproduce this.
However, as you may have noticed, I'm currently too busy with other things and therefore can only help on issues which are easy to clarify.
This looks like a complicated issue where even firmware changes might be required; I fear that I can't look into this the next two weeks... :-/
The configuration files will be helpful anyhow...
Best Regards, Thorsten.
-
Well, I use an external one already at 2.5A 5V so should be well over needed
yes, this is more than enough
Reading a bit elsewhere here I saw a discussion regarding displays (running 2 on lpc17) where that person had problems with 2 displays until you delayed the display something?this was an issue many many years ago, it's solved and confirmed by many many people.
I couldnt download those files and try myself.check the date of postings first before starting such experiments, because you don't know the dependencies under certain circumstances it could screw up the installation (e.g. SD Card config files, USB driver interaction with Windows, etc)
Use the current firmware, other versions won't help to find the issue and could cause new issues.
Also Im using 5V displays but the 74HC595 as it was easier to get at the time (which the other guy also did).A 74HC595 has to be used, the 74HCT595 won't work reliable, confirmed by some users that 74HC595 is the better choice.
That's the reason why you find this chip in the schematic: http://www.ucapps.de/mbhp/mbhp_core_lpc17.pdf
but if you still have the file with display delay I could try that as well?(just to repeat:) the change is already in the firmware since some years.
It could make sense to check your hardware if certain devices are removed.
E.g. did you already remove the MBHP_IIC_MIDI modules from J4A?
If they are faulty and cause a short circuit after power-on, similar behaviour could be observed...
And what happens if only a single LCD is connected?
Best Regards, Thorsten.
-
Great work! :)
Did you consider to use footswitches for controlling recording and loop points?
See this video for a usage demo:
Best Regards, Thorsten.
-
This is correct, it wasn't clear that you don't like this effect.
Maybe it helps you to use conditional events instead of the bank mechanism, it would allow you to enable/disable EVENT_MF depending on the state of another item, such as a button.
More information can be found in the user manual: http://www.ucapps.de/midibox_ng_manual_ngc.html
search for "conditional events"
Best Regards, Thorsten.
-
The firmware is quite stable, it can't cause such effects, resp. it works for many other users.
Could it be a power supply issue?
Maybe your USB based PSU is too weak for the MBSEQ?
I recommend the usage of an externally powered USB hub.
Best Regards, Thorsten.
Meta events/ conditional labels problem
in MIDIbox NG
Posted
Today I spent some time to analyse this issue.
Unfortunately I wasn't able to reproduce it at my side (are you using a MBHP_CORE_STM32F4, or MBHP_CORE_LPC17 module?)
However, I found a potential with the Snapshot Meta event: it didn't use a Mutex while accessing the SD Card, with the danger that any other task could try to access it concurrently. This would result into the error message that you mentioned.
Please try this version: http://www.ucapps.de/mios32/midibox_ng_v1_033_pre8.zip
For the second issue I changed the Snapshot Dump, so that LCD output will be inhibited during dump, which should result into a more deterministic behaviour
Best Regards, Thorsten.