borfo

Figured I'd start a separate thread so as not to crowd the SEQ firmware thread with too much Novation BLM discussion. If you haven't been following that, TK introduced support for using two or four Novation Launchpads as a hardware BLM in the latest firmware. Here are setup instructions for the Novation Launchpad BLM. Download the v. 87 pre1 firmware from (or a later version) to make the Launchpad BLM work. To carry on the features/usability discussion from where it left off in that thread: Is there any way to disable the start(play) and stop buttons in the BLM? I'm finding that I sometimes accidentally hit those buttons while working with the BLM, unintentionally interfering with playback... Are they really necessary on the BLM anyway? They're available pretty easily on the frontpanel... Dropping them from the BLM would free up a few buttons for other functions.

That's my understanding... A 16 step pattern where one step's skip trigger layer is on would actually be a 15 step pattern, since one of the steps would be skipped over. My understanding is: yes, the randomized value would be forced-to-scale before it's played. Any CC values that your synth listens for could be adjusted with these CCs... For example, you could assign CC#7, and send different values for each step to adjust the synth's volume. Or you could assign CC#1 to send modWheel messages at each step. Added - thanks.

This is the discussion thread for the MIDIdocs article "What the Hell is a Mixer Map?" in the Wiki. Feel free to ask questions or make comments or corrections on the article in this thread.

This is the discussion thread for the MIDIdocs article "The V4L as a MIDI Processor" in the Wiki. Feel free to ask questions or make comments or corrections on the article in this thread.

This is the discussion thread for the MIDIdocs article "Novation Launchpad BLM" in the Wiki. Feel free to ask questions or make comments or corrections on the article in this thread.

This is the discussion thread for the MIDIdocs article "Trigger and Parameter Layers" in the Wiki. Feel free to ask questions or make comments or corrections on the article in this thread.

This is the discussion thread for the MIDIdocs article "Building a SEQ V4" in the Wiki. Feel free to ask questions or make comments or corrections on the article in this thread.

I've started putting together a collection of articles in the Wiki... Still a work in progress, obviously, but I'm planning on writing a bunch of articles that go a little more in depth on specific features, concepts, etc. than the user manuals on uCapps do. ...Articles that might help people new to MIDIbox to understand the devices, or which might even help experienced users discover workflows they hadn't thought of on their own. http://www.midibox.org/dokuwiki/doku.php?id=mididocs:index Feel free to add your own articles or link to existing ones. I'm going to be mainly covering the SEQ V4 and V4L, since I haven't built any other MIDIbox devices. Hopefully others will add articles for other MIDIbox devices. I'm going to start a discussion thread in this forum for each article so people can discuss, comment, make corrections, ask questions, etc. without having to register a wiki account. I'll link each thread to the related article on the Wiki.

I'd love a really easy quicksave function for patterns. ALT+pattern slot to save just one track group's pattern into that pattern slot would be great. In track mode, pressing and holding Alt could be used for trigger layer settings - Press and hold ALT - press one of the left round buttons to select which of the 8 trigger layers you're working with - then press buttons in each row to toggle that trigger layer on and off for the corresponding track/step.

I've only got two usability suggestions - this thing is totally usable as-is, but with these two additional things, I don't think the extra buttons on a 16x16 would really be missed. There should be a way to toggle the tracks that are displayed between tracks 1-8 and 9-16. Maybe button 3 on the right side could be a track toggle button: when green, tracks 1-8 are displayed, when red tracks 9-16 are displayed. Is there currently a way to change which octave of notes is displayed on the BLM? If not, it would be great if you could page up and down to display higher or lower notes. Maybe a shift button could be added at the bottom of the right side buttons (on button 8), and shift+button 1-7 could select which octave is displayed on the BLM - if the octave select buttons lit to show which octaves have active notes, that would make it easy to see which octave-pages a user might want to look at. ...only suggestions though - this thing is very usable exactly as it is. Thanks again. edit: this is soooo much better than using the lemur emulator... Touchscreens are really no substitute for physical buttons... Fun fun fun.

Cool. Seems to work now. This version also seems to need libasound2-plugins:i386 - when that's not installed, there are no devices in the midi in dropdown. Once it's installed, the emulator works. sudo apt-get install libasound2-plugins:i386

I'm getting a compile error when I try to build - am I missing an obvious dependency? Compiling UdpSocket.cpp ../../Source/UdpSocket.cpp: In member function ‘void UdpSocket::disconnect()’: ../../Source/UdpSocket.cpp:137:26: error: ‘close’ was not declared in this scope close(oscServerSocket); ^ ######## That's coming from here: //============================================================================== void UdpSocket::disconnect(void) { #ifdef WIN32 closesocket(oscServerSocket); WSACleanup(); #else close(oscServerSocket); #endif oscServerSocket = -1; }

This new version is segfaulting shortly after the SEQ starts playing the sequence. It's fine as long as the SEQ is paused, connects to the launchpads, displays notes, notes can be toggled on and off, etc. But about 4 beats after playback is started, it segfaults. If playback is already running when you start the emulator, and the current step is not displayed on the BLM (ie: it's in a different step page - eg: BLM shows step 1-16, the current step is step 31) it will run ok until the step indicator is shown. It will segfault about 4 beats after the indicator appears on the BLM. The old version from yesterday doesn't segfault. Here's gdb output: (gdb) run Starting program: /home/rob/Desktop/BLM1.1 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0xf7831b40 (LWP 23578)] [New Thread 0xf6b7bb40 (LWP 23579)] [New Thread 0xf61ffb40 (LWP 23580)] [New Thread 0xf57ffb40 (LWP 23581)] Program received signal SIGSEGV, Segmentation fault. 0x080e7ee2 in juce::InternalMessageQueue::dispatchNextInternalMessage() () (gdb)

One other thing: I guess you're compiling MIOS Studio and the emulator on an i386 system? They don't run on 64 bit ubuntu 14.04 unless you install some i386 libraries: apt-get install libfreetype6-dev:i386 libasound2-dev:i386 libgl1-mesa-glx:i386 libgl1-mesa-dev:i386 They work on 64 bit linux if you install those libraries.

It works almost perfectly, and it's great. Thanks so much for getting this working. Amazing that you were able to do it so fast, too. The only bug I've noticed so far is that sometimes the red step indicator line gets left behind, and sometimes notes disappear until the step indicator line makes its next pass. Here's a video: http://youtu.be/zgrTF639Nek you can see the bug happening at around 17 seconds and 27 seconds. Sometimes a red step indicator line is left behind until the step indicator makes its next pass. In the video only one line is left, and it's left in the same place each time, but I've seen several red lines left at once, and they are not always in the same column. Also, sometimes the green active steps disappear after the red step indicator line passes. They are restored on the next pass of the step indicator. You can see this happening with the note in the first column of the second launchpad at the start of the video, and with the same note a few more times throughout the video. It seems that the place(s) where notes disappear and step indicator lines are left depends on the layout of the notes shown on the BLM. Different note patterns leave lines and have disappearing notes in different places. When notes disappear from the launchpad, they also disappear from the onscreen display. When the red line is left behind, it's also left behind on the onscreen display. I'll save usability suggestions for a dedicated discussion thread. Thanks again...

I assume the top row of buttons selects the step page (steps 1-16, 16-32, etc.) - if you can let me know how the side buttons are set up, I'll write a "using novation launchpads as a BLM" article as my first wiki documentation article. If 4 launchpads are connected, do the second horizontal row of round buttons, and the extra 2x8 columns of vertical round buttons do anything? That reminds me, actually, I should also write a "using a Seq V4L as a force-to-scale device and midi effects processor" article, to document the use of that V4L force-to-scale LiveKeepChannel feature you added recently.

Haha - wow. Amazing. How is the device from a technical standpoint? I guess it wound up handling midi signals fast enough? I use linux for everything - if you could build a linux version, that'd be great.

Thinking about it a bit more, I guess the current implementation does allow this relative chord/note functionality with the root=keyb in combination with transpose, although I can think of a few limitations that may be present in the current implementation. Most significantly: While you could easily transpose a chord progression properly from one mode of one key to another key in the same mode (eg: chords in C Major could be transposed to E Major without losing the chord progression relative to the key/mode/scale), transposing from (for example) C major to D Dorian may not work like this, depending on how the force to scale rules work - all the chords/notes would be in key, but a i-iv-v progression may no longer be a i-iv-v progression if the force to scale rules don't coincide perfectly with the way note positions shift between all scales. The notes in C Major and D Dorian are the same, but a i-iv-v in C Major is C-F-G, while a i-iv-v in D Dorian is Dmin-G-Amin. If I'm understanding the current implementation correctly, by moving the force-to-scale setting from C Major to D Dorian and sending a transpose +2 semitones (D) message, For a i-iv-v progression in C Maj (A, B, C chord types) you'd wind up with D G A, which would then be forced into the D Dorian scale. Would the current force-to-scale rules force the notes in these chords to become Dmin-G-Amin? If so, and if this would hold across any scale, you're a genius, TK. While I still think a i-ii-iii-iv... implementation would be a lot more intuitive (particularly because in minor modes, transposed and scale-forced "ABC" chord types would often be playing minor or other non-major chords), the current implementation probably works with the root=keyb + transpose workaround, and conceivably works across all keys/scales/modes. Amazing. I'm definitely planning on doing documentation work. I've already started planning a few articles for the wiki.

Hm... I didn't think the current firmware transposed chords relative to the root note of the selected scale. To duplicate the way I tested: Set up a chord track with div=1, length=1. Put an "A"-type chord on the first step. Set force-to-scale on, and set the scale to C Major. The SEQ now plays a C major chord. Move the force-to-scale root note up to C#, D, D#, E etc. The chord played doesn't become C# Major, D Major, D# Major, E Major etc. Instead, force to scale seems to be applied to fit the component notes of a C Major chord (C E G) into those scales, so in the scale of E Major, the notes become C# E G# (or something similar, I'm not sure exactly how the force-to-scale rule works), rather than becoming an E major chord (E G# B). But I'm not also transposing the note. I guess you're saying that I could change the force to scale setting, and then also send a transpose message to the track - so: set force-to-scale to E Major, and then also send an E to the track on a transpose bus... OR, set the force-to-scale root note to "keyb", and then all I'd have to do is send an E to the track on a transpose bus or from a MIDI input. Hm. I guess that does accomplish what I was thinking, although I'd argue that it's less intuitive... I did realize you could set the root note to 'keyb', but it didn't occur to me that keyb+transpose would work like this. I was also aware of the CC for scale root... But with scale root set to "keyb", can the root be changed by a note received from a bus track? If not, maybe "bus1, bus2, etc." could be added as scale root settings... This would be easier than setting up a bus track for transposition, then also having to send a CC to change the scale root. But I guess a hardware loopback would also work for this... Interesting... I hadn't thought of this approach. I'll have to try it. Sounds like it would probably work, although I'd also argue that it's less intuitive than having a relative note track type. I guess the approach you suggest above for chord tracks (scale root=keyb, send transpose message to track) would also work to some extent. Haha... This device already does everything - I just need to figure out how to work with it in more advanced ways. Anyway, just an idea.

I had a thought on chord and note handling that would preserve chord progressions and melodies across all possible scales: In 7 note scales, there are predictable basic chord shapes - there is a i, ii, iii, iv, v, vi, and vii chord - in a major scale, these are maj, min, min, maj, maj, min, diminished - in a minor scale they are min, diminished, maj, min, min, maj and maj. These chords are easy to find from the notes in the scale - simply take the root note of the chord, and add the notes that are 2 and 4 notes up from the root, looping around to start of the scale if necessary. eg: in C major, the notes are C D E F G A B - chord i is C major - C x E x G x x . Chord iv is G major - x D x x G x B - etc, etc. I believe this rule holds for all 7 note scales, and a friend who is much more of a music theory expert than I am says that the "2 steps up + 4 steps up" rule would produce good-sounding note combinations even in pentatonic or whole note scales, or other non-7 note scales. Sometimes you might want to add a 7th, a 9th, an 11th, or a 13th - those notes would be easy to find algorythmically from a scale as well. The SEQ's force to scale feature defines a key and a scale root note. I was thinking that a new track type could be developed for the SEQ - call it a ChordNum track type. Force to scale would always be active for this track type. With this type of track, in edit view for the main parameter layer, each step could be set to number 1 to 7, with an octave offset. That 1-7 number would be used to find the corresponding chord in the selected scale. eg: If force-to-scale was set to C major, a "3" chord would play as E minor. If the user changed the force-to-scale setting to E natural minor, the 3 chord would now play as G major (the iii chord in the scale of E nat. minor) - this way, chord progressions would be preserved across different force-to-scale settings, but with the chords changed relative to the selected scale. ############# New types of trigger layers could be added that would add 7ths, 9ths, 11ths, or 13ths to the chord. Again, these notes would be calculated based on the root note of the chord, and the force-to-scale setting. Trigger layers could also be used to decide whether to play the 1st, 3rd, and 5th notes (the notes that make up the basic chord itself) - that way a user could choose to play only the chord root note and the 5th, for example. If these 1st, 3rd, 5th, add7, add9, add11, and add13 trigger layers were parameter layers instead, an octave offset could be set, and "---" could mean "don't play this note". This would allow users to specify different chord shapes/variations. ############## The advantage of this is that chord progressions would be preserved across different scales (eg: a i - iv - v would be a i - iv - v to fit whatever scale was selected), and only the key would change with the force-to-scale setting. Currently, the way the chord track type is implemented, if you choose a chord type A with force-to-scale set to off, you'd get a c major chord. If you set force to scale to on, and choose the C major scale, you'd still have a C major chord. But of you change the force to scale setting (for example, moving up the major scales - C#maj, Dmaj, etc.), then the chord changes - it doesn't stay a major chord (C# major, D major, etc.) because the force-to-scale rules are being applied to the component notes, changing the chord type. This means that if you set up, for example, a i-iv-iv chord progression, and then change the force-to-scale setting, you won't have a i-iv-v progression anymore. ################# It would also be useful to have a NoteNum track type - where instead of setting an absolute note (C#, F, A, etc), the user could choose numbers 1-7, representing the relative position of the note in the selected scale. These notes could also have an octave offset. When the force-to-scale setting is changed, the note played would be the note in the selected position relative to the selected scale, rather than the current implementation which takes an absolute note and moves it up or down one semitone to fit the selected scale. EG: a "3" note in the scale of C major would be an E. If force to scale was changed to G harmonic minor, the note would become Bb (the 3rd note in that scale). This would preserve melodies across all scales. ################# I'm not sure how transposing should work with this sort of chord/note implementation. You'd want to transpose a chord or note up or down within the selected scale, clearly (so a "v" chord/note would become a iii or vii chord/note, etc.) - I'm just not sure how the input notes should be applied to accomplish this in an intuitive way. Maybe these relative chord/note track types shouldn't be transposeable. Since they are tied to the selected scale, maybe they would be best used as either fixed tracks to be played out to a synth without transposition, or as sources rather than targets for transposition/arpeggiation (ie: sent to a bus to arpeggiate or transpose another track). ################# Thoughts?

That's unfortunate - the "signal every 1ms" is particularly weird... Do you mean incorporating the translation into the windows/mac emulator program, or the lemur emulator? I've been meaning to ask actually: Is the windows/mac program Juce-based? Looking at the source in the blm_scalar_emulation directory, it seems like it probably is... If so, is there any reason why it wouldn't be easy to compile for Linux? I haven't tried yet, but I've been meaning to give it a shot and see if it works.

He's out of stock. New boards have been ordered, and he told me he expects them to arrive relatively soon, and when they are they'll be back up on the midibox shop page.

Switch caps are still available.

They should both fit the same tl1100 switches. These caps are Length: 9.80mm - Width: 5.50mm - Height: 11.20mm - the caps referred to in the SEQ parts list are these (Length: 12.1mm - width: 5.9mm - 11mm height): http://ca.mouser.com/ProductDetail/CK-Components/PE-BK/?qs=sGAEpiMZZMsqIr59i2oRctAaD8wfjvPOMa0ZOJ%252b2auk= So, mine are ~2mm narrower, ~.4mm less wide, and ~.2mm less high No worries/no hassle if you don't want them.

Cool. Looks like regular mail (ie: no tracking number) to Norway will be $6 at the most. Probably cheaper than that - I'll check at the post office. PM me your address and I'll just mail it out and let you know how much it cost. You can just paypal it to me after I mail it.