stryd_one

Ahh a new point release, congrats :) Pics! ;D

Guys, the scale engine and chord engine is already in seqv3... I'll rip that out and wrap it in C, so no need to worry on that one. :) Oh FWIW they work kinda like what you've described, so you were on the right track :) Something to consider... Whereabouts in the chain the chord and scale generators go - at the beginning or at the end? There are arguments either way... I guess both would be best... jr, for the kind of thing you are talking of, you want it to have the chord generator at the input, and run a normal up/down arp pattern. You select major chord, hit C, it generates the C major chord and sends all of it's notes to the arp buffer, and they get stepped through from there as incoming note 1, 2 and 3. Well the idea was originally that you would learn to play the chord and let the arp save you from doing a mexican wave with your fingers. There's a good reason for that - you might want to arpeggiate a major chord and then a minor after that, and then change key...and you don't have time to go through menu's or hit buttons to change your chord type or scale every time. Remember that an arp is a special effect, not a substitute for skillful playing. It is a powerful tool, use it wisely :) Edit: Oh yeh Martin thanks for mentioning Converter :) I always wished it supported more ports though :( If I could just run a few Soundblasters at once, it'd own...

Or you could try Wilba's JB Weld trick...

Well we''d have to make it service the SR's a lot quicker, and it would only have enough ram for a few more ports so maybe they could just run from the PIC pins... although I'm not sure the PIC could handle bitbanging that many ports at once... It would be nice though ;) To be honest though I don't think I'd want to take on something requiring that much work (software UART) ... Just because I don't have enough time. I would buy this router if one existed ;)

I dunno man... If you've got it routed correctly so that you can see for example midi notes being sent to the zoom, and you know a message is being sent... I figure maybe it's sending some kind of non-standard bytes (0xF4, 0xF5, 0xF9, and 0xFD) so it is not recognised, or you are filtering it out, in your software.

Heya guys, Well I won't start my rant on the pitiful state of computer MIDI interfaces these days, but I'll get straight to the point: I wanna big MIDI router. From the IIC_MIDI page, TK has pointed out that four of these modules is the maximum that will allow solid timing, but I was thinking that perhaps we could use a multi-core design using the CAN bus to transfer MIDI between the cores to allow greater than 4x4 routings without the limitation of the IIC bus... I'm not sure if that's really going to work out though, as I haven't seen MBLink working yet so I know very little about the operation of CAN in reality. Any thoughts?

http://stage6.divx.com/user/Denkitribe/video/1091421/KORG-Electribe-MX-(2) (fast forward to 1:30) seems to me it's more of a controller which can be locked to a set of notes and holds the notes until a quantised time... Not reallly an arpeggiator, but still cool.... But it's pretty far from this skeleton which is more of a traditional arp... Once we make a C version of TK's scale/chord engine it should be pretty easy to make a custom app for that, with the clockbox code for the quantising... The midibox_master_keys that's on my drawing board has all but the quantising built in but that's a fair while away at the moment.

That sounds interesting... Does it actually play a pattern or is the pitch completely controlled by the pot, but restricted to the scale/rhythm?

Another good reason to use the Step A CS :) I think that's a fine basic CS, if you look at screens from the k5k you can see that most of it is driven by the encoder and the buttons around the screen, it's just a bigger screen is all :) Good call :) I agree with all that. Thanks for the offer of hosting :) Maybe we should attach milestone builds to this thread too?

Maybe that handshake is sent via USB and not MIDI? Does their editor work OK without USB plugged in? Edit: What's Maple?

Where'd ya go bill? What do you think of the above, should I get into it, or are you still working on your code?

:o OMG that's awesome! You're really working some magic on these new PICs. Sometimes I think if you got another 64k of code space you'd become immortal ;)

Yeh this is up there with the best for sure. Freakin awesome Wilba! When you gonna bring her over? I wanna touch it :-* ;D Edit: I wonder if there might be room in v2 for controlling digipots so that feedback could be saved in a patch?

Not bad! :D How much was the ship to .au?

That is a nice IC, but having taken a look at it, I think it might be beyond my skill to use it :-[ Maybe for version 2 ;) Although, a joystick port could be cool, I could make a simple circuit to switch it between joysticks and midi keyboards... Is that what you meant?

Ohh I didn't realise it was dropping out at 8 mins... I hate to say, but that is kinda soon, I've done a few tracks over 12 minutes in the past, and that's just music, not counting film and stage stuff :-\ It would be a shame not to be able to use the seq for those tracks :(

Ahh 96ppqn :) I'm stuck in the past at 24 hehehe I coul 've sworn I saw code with a low and high byte?

Sorry haesslich! I thought I had replied to this but I must have closed the window or something... Anyway I just wanted to say I didn't mean to disappear on you there :)

Couple more... Polyphonic arps (although this could be implemented using two concurrent arps, with different patterns, but using the same incoming notes) Manual stepping through the patterns. The sub-clocking routine from the vX could be used here but I suspect that it wall add extra functionality that a lot of people don't want, aka 'bloat'... I might wait until it's complete and then branch it off, but if you guys want it and nobody minds then I'll include it from the beginning. Yeh I don't know if it's been mentioned yet either, but I think it's implied :) Definitely a must-have, and should be trivial to implement. I would like to include the auto syncing feature that AC and TK are using, where it runs on internal clock and automatically locks to incoming midi clock F8 events, but I haven't seen the code yet so I won't make assumptions. Yeh I think that a small simple CS is best for most uses. Maybe an expanded CS could come later... I think that the framework Bill has laid out gives a pretty clear indication of what is required code-wise, and we've got a solid set of features now, I think we need to make an organised list of the features (I'll volunteer for that one once bill has shared his opinion on the last few posts), and the next thing to do would be to consider the actual usage of the box - IE how do we want to program it and use it... Oh hey, regarding the 32B buffer, I see that's for notes alone, I reckon that's way more than we need.... but how many notes do we want it to be able to buffer? (per arp) As soon as we make it :) I'll be back on work on Monday which means I'll have at least a few hours on public transport every day to work on this. *looks at AC* Final random thought: I like your note ordering algorithm bill :) I was thinking... It would be good if we could make it optional as to whether to sort by note number or chronologically.

It's a shame that it's not free... Especially as they give the impression that it is! I have to say, that we don't endorse piracy here, which means that this may not be a good option. I do like the layout of the display though. I think that MIDI-Ox or MIOS Studio do a good job at this, and they're both generously provided free of charge. :)

Gday nitrus. Not sure why you posted this in 'parts questions'? Mind if I move it? It seemed like the software is free but it also seems you're talking about cracking it?

Heheheh slow down there buddy :) You just posted a parts question, with a MB64 in the title, in the HUI forum... Now that's confusing! No big problem though :) As for USB power, short answer is yes, long answer is maybe.... It will depend on your power requirements. If your box draws too much power, then the USB buss will not be able to keep it running.

Another top example of recycling at it's finest :)

There are a few ways that you could do something like this, and the best will depend on lots of factors... I would probably store the button/LED on/off states in an int (or 2 chars) and update the CS accordingly. You could use arrays to 'group' these ints. Hope that helps!

Just thought of a nice feature... Delays, with pitch and pan modulation. It's not strictly an arpeggiator feature but it could be handy? I like the arp-x8 thing where it has multiple arps with channels and keymaps too... How about xfading/morphing between arp patterns? Ahh multiple outputs for sure.... Hey bill as for the patterns, why not make them user-editable? And how about Program Change for selecting them? Was thinking about the remote control, I dunno if CC# is the best thing for BPM as it doesn't allow enough range... although it would be good for modulation stuff like arp speed, note length, velocity... Octave range could be done like that too but it would be really cool if it could be done with the keyboard as well... Maybe we could use a certain message like a CC or an unusual note combination to put the arp into an editing mode or something? Anyway I think it's best to allow *everything* to be controlled by sysex and CC's, just for compatibility with other devices... But sometimes one way is more elegant than another... I always wanted an arp that would latch incoming notes, and then allow me to mute and unmute those latched notes by pressing the same key... Most of them just latch them in forever (until you hit stop anyway, or they're rolled off the stack of incoming notes) and I played one once I think * that let you remove the latched notes by hitting the key again, but then when you hit the key a 3rd time and turn it back on later, it is in a different order to the original, so it sounds different. (* Maybe I dreamed that heh) Now I thnk of it, better still... Have it latch all incoming notes, if the same note is struck again, then it will mute/unmute that note if the velocity is >63, and remove it from the stack for velocity (X)-62. That way you have full control over latching with a single algorithm, if you set (X) = 1, it will always latch notes with a note-on, and will unlatch them with a subsequent low-velocity note, or mute them with high velocity notes, and if you set (X) to zero, it will unlatch the notes as soon as you release them... (Note that this requires converting incoming 0x8n events to 0x9n, velocity 0, events. I don't think that should be a problem, I don't think I ever saw a synth that didn't support 0 velocity as a note-off) What else... Individual velocity modulation for each note in the stack... I dunno.. I started writing this post with that first idea and all the rest fell out of my brain. "Sorry about the mess" He said, and tossed the bartender some credits. Surely someone else has a feature request? Everyone seemed keen, until I said "what do you want it to do?" ;D Edit: Oh yeh how about 'fills'?