borfo

TK's Current Drunkenness Status: Drunk. Just sang the worst-ever Karaoke version of "Sweet Caroline". Trying to recruit everyone in the bar to play in the Neil Diamond cover band he just decided to put together.

The thing with adding two dedicated muting "views" is that there are basically only 8 function keys on the right side, since not everyone will be using 4 launchpads... So, the question is is muting and soloing important enough to tie up the last two remaining buttons, or should they be implemented in a way that leaves space for future features? Also, there are a lot of functions already assigned to the right side track buttons, and a lot of LED indicator states are already required there. Those buttons are already pretty "busy". Here are two more ideas: Add a "button mode" button: Get rid of PLAY and STOP. Add a "BUTTON MODE" button, which has four possible states: off = left buttons select the active track (the current functionality) red = left buttons MUTE tracks green = left buttons SOLO tracks yellow = [currently not used, could add something here later... leave it out of the toggle cycle for now] Press BUTTON MODE repeatedly to cycle through these states. Pros: - uses only one button on right side - "yellow" state is unused, can be used for future function ######OR###### Add a "Track Settings View" mode: Well, there's already a track view mode... Maybe call the new view "Settings View". In this new "Settings View" mode, tracks are represented horizontally (track 1 is the first row, track 2 is the second, etc. - just as it is now). Each column of square buttons represents one setting that applies to the whole track: column 1: MUTE (red=on, no color=off) column 2: SOLO (green=on, no color=off) Other columns could be added in the future, as needed... For example: FORCE TO SCALE on/off, FX Delay on/off, HOLD on/off, SUSTAIN on/off, SYNC TO MEASURE on/off, etc. 16 columns of settings would be available. The top row of round buttons (step indicator buttons) could be used to perform bulk actions on the column below - eg: press top button to mute all tracks, ALT+top button to unmute all tracks. Pros: - only needs one button on the right column - both MUTE and SOLO would be accessible at the same time - 14 extra columns for other settings to add in the future - doesn't interfere with the way the left track buttons are currently implemented I think I like this last option, because it's not just "all about muting" - it creates a new view which could be useful for 14 other functions in the future... Maybe the "Loop mode" functionality discussed in TK's BLM manual page could also be added here eventually (one column of buttons could be LOOP START, another column could be LOOP END, press LOOP START+Step Button to set loop for a track...) I think it would also be useful to be able to set track length from the BLM - maybe this could be done in this Settings Mode as well: One column could be TRACK_LEN - press TRACK_LEN + top row Step buttons to define the track length (16, 32, 48, 64, etc.)

Here's another idea: Use the round step buttons along the top of the launchpad: Get rid of PLAY and STOP. Add MUTE and SOLO buttons. While MUTE is held, the top row of 16 buttons represent the 16 tracks, Muted tracks appear as red. Press MUTE+step button to mute or unmute a track. While SOLO is held, the top row of 16 buttons represent the 16 tracks, Soloed tracks appear as green. Press SOLO+step button to solo or unsolo a track. ALT+MUTE could clear all mutes ALT+SOLO could clear all soloes SOLO+MUTE could Mute All Tracks pros: - even if you're using only 2 launchpads, you'll have access to all 16 tracks at the same time - the mute and solo buttons could be used with buttons other than the step buttons to add future functions later on cons: - tracks are normally on the right column of buttons so it's a bit counterintuitive ################################ I'd also vote for moving the track select button (the button that toggles display of tracks 1-8 or 9-16) up to the top of the column, because it's a special function button... and for moving the MUTE and SOLO buttons to the bottom, just above the ALT button (because they would have the same press and hold behaviour as the ALT button does, while all the other buttons are toggles.) So, I'd vote for the following button order: TRACK SELECT KEYBOARD PATTERN TRACK GRID MUTE SOLO ALT

Does anyone use the BLM without a V4 or V4L frontpanel nearby? If not, the play and stop buttons could be removed from the launchpad BLM interface to make room in the right column of buttons for more functions. I sometimes accidentally hit those buttons while BLMing and mess the song up. I'd rather they weren't there, and just use the V4 itself to start and stop playback. Do other people find the play/stop buttons useful on the BLM? ...I suppose a second alt button could be added - ALT1 and ALT2 - to make a lot of extra room for future functionality - that would give four "ALT" states that could be used: no-ALT + button; ALT1 + button; ALT2 + button; and ALT1 + ALT2 + button

Hi SID people! You're cordially invited to visit the SEQ forum for a minute to this holiday season.

TK's Current Drunkenness Status: A little buzzed. Starting to think you all look much more attractive than you actually are.

TK's Current Drunkenness Status: Tipsy, but could probably still operate heavy machinery.

Not possible apparently - more info here:

Five beers sent. Good point. Erased.

...or whatever your December holiday of choice might be. If he doesn't enjoy alcohol poisoning for some crazy reason, then I suppose he could spend the money on something else. Feel free to repost this in other MIDIbox forums in order to get TK the maximum amount of beer possible. Here are some paypal links: Buy TK one beer ($5 USD): https://www.paypal.com/cgi-bin/webscr?cmd=_xclick&business=Thorsten%2eKlose%40gmx%2ede&item_name=Buy%20TK%20a%20Beer&amount=5%2e00&no_shipping=2&no_note=1&tax=0&currency_code=USD&lc=EUR&bn=PP%2dDonationsBF&charset=UTF%2d8 Buy TK two beers ($10 USD): https://www.paypal.com/cgi-bin/webscr?cmd=_xclick&business=Thorsten%2eKlose%40gmx%2ede&item_name=Buy%20TK%202%20Beers&amount=10%2e00&no_shipping=2&no_note=1&tax=0&currency_code=USD&lc=EUR&bn=PP%2dDonationsBF&charset=UTF%2d8 Buy TK three beers ($15 USD): https://www.paypal.com/cgi-bin/webscr?cmd=_xclick&business=Thorsten%2eKlose%40gmx%2ede&item_name=Buy%20TK%203%20Beers&amount=15%2e00&no_shipping=2&no_note=1&tax=0&currency_code=USD&lc=EUR&bn=PP%2dDonationsBF&charset=UTF%2d8 Buy TK four beers ($20 USD): https://www.paypal.com/cgi-bin/webscr?cmd=_xclick&business=Thorsten%2eKlose%40gmx%2ede&item_name=Buy%20TK%204%20Beers&amount=20%2e00&no_shipping=2&no_note=1&tax=0&currency_code=USD&lc=EUR&bn=PP%2dDonationsBF&charset=UTF%2d8 Buy TK five beers ($25 USD): https://www.paypal.com/cgi-bin/webscr?cmd=_xclick&business=Thorsten%2eKlose%40gmx%2ede&item_name=Buy%20TK%205%20Beers&amount=25%2e00&no_shipping=2&no_note=1&tax=0&currency_code=USD&lc=EUR&bn=PP%2dDonationsBF&charset=UTF%2d8 Buy TK ten beers ($50 USD): https://www.paypal.com/cgi-bin/webscr?cmd=_xclick&business=Thorsten%2eKlose%40gmx%2ede&item_name=Buy%20TK%2010%20Beers&amount=50%2e00&no_shipping=2&no_note=1&tax=0&currency_code=USD&lc=EUR&bn=PP%2dDonationsBF&charset=UTF%2d8 Buy TK twenty beers ($100 USD): https://www.paypal.com/cgi-bin/webscr?cmd=_xclick&business=Thorsten%2eKlose%40gmx%2ede&item_name=Buy%20TK%2020%20Beers&amount=100%2e00&no_shipping=2&no_note=1&tax=0&currency_code=USD&lc=EUR&bn=PP%2dDonationsBF&charset=UTF%2d8 Disclaimer: buying TK a beer gets you absolutely nothing in return, such as firmware enhancements, technical advice or MIDIbox troubleshooting assistance. If you don't trust my links, use the link in TK's sig. Or get his email address from the paypal link in his sig and paypal money to that address directly.

Thanks again - I'll make some time to play with this this week.

Thanks!

Midi to USB adapters work for me with my iPad. DIN MIDI inputs on my NI Komplete Audio 6 also work. Maybe try the MIDIbridge app - it gives you a lot of control over iPad MIDI. You may need to connect your usb-midi interface through a powered usb hub to the CCK, although mine works plugged directly into the CCK. You definitely need to connect the midibox through a powered usb hub though, unless you're powering the midibox with some power source other than USB.

Yeah, it's not a real problem. It's never happened to me in normal use - this was kids mashing as many buttons as they could at the same time. Just thought I'd mention it.

If you're ordering from Midibox-shop.com, the encoders there are fine. (oh - actually looks like they're out of stock right now.)

My brother's kids (age 4 and 6) came over today and played with the novation launchpad BLM on my Seq V4... Well, they mashed a lot of buttons and made horrible noise, anyway. In the process though, they may have found a bug in the Virtual BLM Juce software running on linux - they were able to consistently freeze or entirely crash the linux program by mashing on tons of buttons on the Launchpad at the same time, over and over again for a minute or two. To replicate: mash on buttons on the Launchpad like a five-year-old who doesn't understand anything about how a sequencer works. Probably not a real problem, since nobody would mash on buttons like that in actual use, but I thought it was worth mentioning, since the input overload does consistently crash the Linux program eventually. Sometimes the program just freezes, and sometimes it shuts down entirely.

It's a MagJack SI-60024-f - digikey #380-1117-ND Make sure you get the right one - the pinouts can be pretty different on different eth jacks. (edit: haha - rereading your post, I see you made the same mistake I did by ordering substitutes thinking the pinouts would be the same. Mine fit the board, but I soon found out that even jacks with identical pin configurations can have different pinouts. The SI-60024-f is the correct part.)

It can take quite a while. A few weeks sometimes before you show up on the shipping status page (http://midibox-shop.com/status.html).

Good points... I'll add a simpler example when I have some time. Feel free to edit any of these if you like, by the way - I'm just trying to flesh out a bunch of articles right now, I'm planning on improving them as time goes by. But I'm not at all attached to what I've written - people should feel free to edit them. I actually didn't realize there was a semitone option on the transpose page until right now - I thought it was just an octave shift. Added that option to the article.

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

Thanks - I'll dig into this over the next while. It'll probably take me a while to get my head around the code, but it'll be a good project. I'm going on a sailing trip for a month starting next week, so probably won't see any results for a while though. (on the upside, you probably won't see a flood of feature ideas for a while either... haha)

Cool. I'll dig through the source over the next while and try to understand how everything works and come up with a proposal. Am I understanding the current implementation correctly? When the SEQ is playing, every time it hits a step, it runs SEQ_LAYER_GetEvents(). When the current layer is a chord layer, it hits the chord CASE clause, and runs SEQ_CHORD_NoteGet() four times to translate the chord letter (A-P or a-p) into notes. This translation occurs every time a step is played (in other words, the chords are not stored as notes, they're stored by name - as the equivalent of "A-P..." - and translated into notes when played.) To implement this i-ii-iii-iv... proposal, a "case SEQ_PAR_Type_numChord" clause would have to be added to SEQ_LAYER_GetEvents(). If that clause ran a translator function that required similar processing power to running the current SEQ_CHORD_NoteGet() function four times, that would be efficient enough for the SEQ to maintain timing? ...and when I'm in SEQ_LAYER_GetEvents(), seq_core_global_scale_root and seq_core_global_scale would be the right place to look to find the currently selected scale and root? Or would I have to call SEQ_CORE_FTS_GetScaleAndRoot() to get the current selections?

The chord table could be constructed something like this for a i-ii-iii-iv-v-vi-vii implementation, where #s 1-7... correspond to the notes in the currently selected scale (eg: C Major - 1=C 2=D 3=E 4=F 5=G 6=A 7=B 8=C 9=D 10=E 11=F ...etc.) static const seq_chord_entry_t seq_chord_table[] = { // 1 2 3 4 <----> (6 chars!) {{ 1, 3, 5, -1 }, "i " }, {{ 2, 4, 6, -1 }, "ii " }, {{ 3, 5, 7, -1 }, "iii " }, {{ 4, 6, 8, -1 }, "iv " }, {{ 5, 7, 9, -1 }, "v " }, {{ 6, 8, 10, -1 }, "vi " }, {{ 7, 9, 11, -1 }, "vii " } }; This table would also "just work" in Minor keys and in all modes (phrygian, lydian, dorian, locrian, etc.). Inversions, tonics, note combinations, weird chords (add7 add9 add11 add 13, etc.), etc. could be added in a variety of ways, maybe with other chord letters on the main chord parameter layer (1a, 1b, 1c, 2a, 2b, 2c, etc...), or maybe with trigger layers. Anyway... What do you think? I may take this on as a project eventually if I can't convince you that it's a good idea, but I think this might be a bit complicated for a first MIDIbox coding project, given that my knowledge of C is pretty crap... I'll probably try a few simpler things before this. How complex do you think it would be to implement this as a new chord track type? Would it be easy to check seq_scale_table (in seq_scale.c) and the selected force-to-scale root note and then calculate the chord offsets from that? Are there any obvious technical barriers to implementing this? ...sorry about all these giant wall-of-text posts... Kind of a complicated idea to explain in fewer words.

I've dug into the source code of the chord track type, and I understand how it works... I misunderstood how chord tracks work until now... I didn't realize that all the chords were C variants. I assumed they were all chords in the scale of C, not all C chords. I think the way chords are currently implemented is a bit crazy. I'm going to try to convince you that the implementation I describe in my first post would be more useful. When not transposed or forced to scale, all of the chords and note combinations represented by A-P and a-p are variants of the C chord. A, B, and C are all C major, a, b and c are all C minor. I-N are C Maj6 ... C Maj 12, etc. Here is the source for the chord variants (where 0-12=the notes of the chromatic scale starting at C): static const seq_chord_entry_t seq_chord_table[] = { // 1 2 3 4 <----> (6 chars!) {{ 0, 4, 7, -1 }, "Maj.I " }, {{ 4, 7, 12, -1 }, "Maj.II" }, {{ 7, 12, 16, -1 }, "MajIII" }, {{ 0, -1, -1, -1 }, "Root " }, {{ 4, -1, -1, -1 }, "3rd " }, {{ 7, -1, -1, -1 }, "5th " }, {{ 0, 4, -1, -1 }, "R.+3rd" }, {{ 0, 7, -1, -1 }, "R.+5th" }, {{ 0, 4, 7, 9 }, "Maj.6 " }, {{ 0, 4, 7, 11 }, "Maj.7 " }, {{ 0, 4, 7, 12 }, "Maj.8 " }, {{ 0, 4, 7, 14 }, "Maj.9 " }, {{ 0, 7, 12, 16 }, "Maj.10" }, {{ 0, 7, 12, 19 }, "Maj.12" }, {{ 0, 5, 7, -1 }, "Sus.4 " }, {{ 0, 4, 8, -1 }, "Maj.+ " }, {{ 0, 3, 7, -1 }, "Min.I " }, {{ 3, 7, 12, -1 }, "Min.II" }, {{ 7, 12, 15, -1 }, "MinIII" }, {{ 0, -1, -1, -1 }, "Root " }, {{ 3, -1, -1, -1 }, "3rdMin" }, {{ 7, -1, -1, -1 }, "5th " }, {{ 0, 3, -1, -1 }, "R.+3rd" }, {{ 0, 7, -1, -1 }, "R.+5th" }, {{ 0, 3, 7, 9 }, "Min.6 " }, {{ 0, 3, 7, 11 }, "Min.7 " }, {{ 0, 3, 7, 12 }, "Min.8 " }, {{ 0, 3, 7, 14 }, "Min.9 " }, {{ 0, 7, 12, 16 }, "Min.10" }, {{ 0, 7, 12, 18 }, "Min.12" }, {{ 0, 3, 6, 9 }, "Co7 " }, {{ 0, 3, 8, -1 }, "Min.+ " } }; If you force the track into the scale of C major, many of those chord types become redundant - only note numbers 0, 2, 4, 5, 7, 9, 11, and 12 are in key (and 14, 16, 17, 19, etc.). Only the first group of chord letters (A-O) are in the key of C major - the rest are in C minor, and would be forced into C Major by the force-to-scale setting. (P would be forced-to-scale and become something else, since note 8 is out of key.) It's also worth noting that all of these chord variants are basically the same thing anyway - a "C" chord is composed of the major harmonics that are most prominent when we hear a "C" note anyway - the 3rd, 5th, 7th, 9th, etc. are all in that original C note anyway. When we play a C and its 5th, that's just a slightly different way of playing a C Major chord, where one of the harmonics is de-emphasized. And a C Maj 7 just emphasizes one of the other harmonics that's there anyway. So this long, hard to remember list of 32 chord variants is really just a list of 32 small variations of pretty much exactly the same thing. Since the chord implementation is so complex, I imagine nobody uses it without force-to-scale enabled - trying to keep track of the transpositions and chord letter selections required to keep a chord progression in key without force-to-scale enabled seems like an impossible task to me anyway. So, assuming chords are only used with force-to-scale enabled, and if force-to-scale always renders at least half of the chord shapes (A->P +p or a->p +P) redundant because when they are forced to scale, they become the same as the other chord shapes (when in a major key, a-o become A-O, and when in a minor key the reverse happens, and in either case, P and p are out of key and would be transformed into something else). So, disadvantage #1 is that more than half of the chord shapes are redundant. Disadvantage #2 is that these chord letters are non-intuitive and hard to remember. Particularly confusing because they don't correspond to note names, which are also letters. (eg: Chord "A" is not an A Chord) Disadvantage #3 is that the current implementation relies on the force-to-scale rules to properly transpose notes up or down in particular circumstances to ensure that the right chords are produced. I haven't looked too closely at the force-to-scale rules, but even if they do perform correctly in all possible circumstances, always creating the proper chord, this would seem to be a convoluted implementation, with an extra possible point of failure. Disadvantage #4 is that in order to play a chord progression, you need two tracks - one chord track, and one Bus track to transpose the chord track. Disadvantage #5 is that in order to play a chord progression, you have to know the notes in the scale you select. Not everyone using the SEQ will have a particularly good grasp of music theory. (I know I don't...) Take your example in Tutorial 3 for example. http://www.ucapps.de/midibox_seq_manual_tut3.html There, you play a progression in C Major - Em-Am-C-Em. It is relatively simple to do that, because it's in the key of C. 1: set force to scale to C Major 2: Enter a bunch of Chord letters in the chord track - all the letters correspond to combinations of the notes in a C Maj. Chord (you would have gotten more or less the same results if you entered a-o minor chord variants, since they'd be forced-to-scale to C Major and become major chords anyway) 3: send E-E-A-A-C-C-E-E to the chord track on a bus ...Transpose + Force-to-scale turns that into an Em-Am-C-Em progression. ###################### In the Key of C Major, that progression is a iii-vi-i-iii progression (Em, Am, and C are the 3rd, 6th, and 1st chords in the key of C Major) Much more complex though, if you wanted to play a iii-vi-i-iii progression in the key of Eb Harmonic Minor, because while everyone knows the notes in the scale of C Major (and could figure out the notes corresponding to a iii-vi-i-iii progression), not everyone knows Eb Harmonic Minor so well... Notes in Eb Harmonic Minor are: Eb F Gb Ab Bb Cb D Eb Chords in Eb Harmonic Minor are: i: Eb Minor (notes: Eb Ab Cb) ii: F Diminished iii: Gb Augmented (notes: Gb Bb D) iv: Ab Minor v: Bb Minor vi: Cb Major (notes: Cb Eb Gb) vii: D diminished So, a iii-vi-i-iii progression in the key of Eb Harmonic Minor is: Gb Augmented - Cb Major - Eb Minor - Gb Augmented To play that progression, you would have to: 1: set force to scale to Eb Harmonic Minor 2: Enter the same bunch of chord letters in the chord track, all of which would correspond to C Major (or enter lower case letters a-o, it doesn't really matter since it will be forced to scale anyway) 3: send Gb - Cb - Eb - Gb to the chord track on a bus ...Transpose + Force to scale turns that into the desired progression. BUT, in order to do that, the user has to know the notes in Eb Harmonic Minor. The current chord implementation can't be used effectively by users without a good grasp of music theory - you have to know the notes in whatever key you select in order to use the chord track effectively. With the current implementation, the chord parameter layer isn't really doing much of the hard work in playing a chord progression... It's left to the user to choose the chords that fit the currently selected key. All the chord track does is takes the input note, plays some combination of root, 3rd, 5th, etc. of that note, and forces the result into the chosen scale, which creates minor, augmented, diminished, etc. chords as appropriate. But the user's doing the hard work of remembering what notes are in the key in the first place. And it would become even more complicated if the user changed the force-to-scale root note, for example by choosing the "keyb" option. You could easily wind up producing all kinds of off key music if you didn't plan everything very carefully... ####################### If a i-ii-iii-iv-v-vi-vii chord track implementation (as I describe in my first post) was used, then to accomplish what you did in your tutorial: 1: Set force to scale to C Major 2: enter a iii-vi-i-iii progression in the Chord track Done. To transpose that progression to Eb Harmonic Minor: 1: Set force to scale to Eb Harmonic Minor. Done. No music theory knowledge required. Transposing into any of the other 166 scales on the SEQ would be just as easy.

This is the discussion thread for the MIDIdocs article "Force-To-Scale" in the Wiki. Feel free to ask questions or make comments or corrections on the article in this thread.