stand alone arpeggiator

[stryd_one]

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.

Lets see... I don't know if it's been mentioned, but syncing to the MIDI clock would be nice.

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.

What I would like this to be, and this is just industrial design part of it, is very small. maybe fit in a 3x5in project box. Something that wouldn't look out of place sitting on my controller. Small. So I guess that means just a CORE module and the 'step A' control panel. I can't really envision a need (I'm sure there would be a desire, though) for any larger control surface.

Yeh I think that a small simple CS is best for most uses. Maybe an expanded CS could come later...

Is there anything I can do to contribute to the project? You can count me in for testing, for sure, but I'd like to know if there's anything else I can do.

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)

Don't mean to be nagging, but what's the ETA of the software? I'd love to be building this now, instead of a SID (so much simpler!)

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.

Edit: You know, a harmonizer would be cool too....  ;)

*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.

[stryd_one]

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?

[bill]

Where'd ya go bill?

Heheh, i was very busy as usuall... :)

They are tons of great ideas here, and most should be implemented.

If we aggree on the "base" code i allready posted, then yes, you should (as anyone who like to) start to write code.

(i did not much since last post)

but i think as it's more or less a colaborative work, we should be very carefull on few points like to :

- Keep as much comments as possible in C files.

- Separate function as clearly as possible.

- Dont think there is a "normal" way of use.

- Keep it simple (to use)

- Then, dicuss about the new code. (we can post changes on this topic, or in the wiki page)

- And of course create "releases" (and keep all versions available)

I have pretty much room to store files on my website if needed. Dont hesitate to ask me for 'free hosting'.

What do you think ?

I'm affraid we now have to start to aggree on a "base" control surface to input values and tweak the app ?  ::)

( i still like the step A cs idea  ::) )

And now about the last posts :

Yey, i'm happy that pretty much peoples are interested and have ideas and opinion to share :)

First, i LOVE the delay idea :)

I also like the "chord generator". Got some nice code here : http://jambonbill.free.fr/midibox-kb/Arp/chords/index.htm )

The sync : of course, it must be synced to the incoming midi clock events, but i think it has to be enabled manualy better than automaticaly, because of the "live" thing :

When i play it live, i dont want to have any lag when i hit a chord, so in my case, i prefer to have the choice to enable the "auto sync".

[bill]

Don't mean to be nagging, but what's the ETA of the software? I'd love to be building this now, instead of a SID (so much simpler!)

Dont hesitate to do it, it's allready working even if it's dead simple atm. This same hardware can be used with no changes for your SidBox later !!

[Martin_Haverland]

Nice ideas already...i just want to add one...

Anyone interested in the Electribe MX type arp? It is so musically useful that i use it the whole day when programming patterns. Not only for synth parts but for drums as well. (It has different mode for this...)In fact my master keyboard is getting dusty already...

The only thing that is not possible with it is the velocity thingie (all electribes have only 2 velocity levels - unfortunately...)

It's a highly useful performance type arp (arp may be really the wrong word but korg named it like this...) that i really would love to use on all kind of synths....with a really LONG ribbon it would be a completly insane midi instrument and controller :P. (something like the video tape diy ribbon controllers comes to my mind...)

Functionality:

Mainly, it uses a touch sensitive ribbon (switch/piezo drumpad/whatever and pot?) and a fader (pot) for arp control.

You can set a scale (melody arp) or rhythm type (drum arp) and select a root note (including octave, this could be done via midi in...real time), then you play the notes via the ribbon touch (note/rhythm on/off), the gate via ribbon position (pot) and the pitch/note number via the fader (pot) - incredibly simple and intuitive to play...

The note on/off is synced to the clock / rhythm struct of course :)...

I was hoping to find an arp discussion on midibox with an app sceleton to fit this task for quite a while...

And am wondering how much developement effort it would take to implement such functions in this minimal arp sceleton here?

This may be a big side-step from the ideas already posted, but i'm interested in opinions especially from the people in this thread ;)

Kind regards,

Martin

[stryd_one]

This same hardware can be used with no changes for your SidBox later !!

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 :)

we should be very carefull on few points like to :

- Keep as much comments as possible in C files.

- Separate function as clearly as possible.

- Dont think there is a "normal" way of use.

- Keep it simple (to use)

- Then, dicuss about the new code. (we can post changes on this topic, or in the wiki page)

- And of course create "releases" (and keep all versions available)

Dont hesitate to ask me for 'free hosting'.

What do you think ?

i prefer to have the choice to enable the "auto sync".

Good call :) I agree with all that.

Thanks for the offer of hosting :) Maybe we should attach milestone builds to this thread too?

[stryd_one]

Anyone interested in the Electribe MX type arp? (arp may be really the wrong word but korg named it like this...)

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

[stryd_one]

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

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.

[jrkirkish]

Well, I'm trying to do my part by getting my head around the chord generator. Here's what I've found:

http://en.wikipedia.org/wiki/Chord_%28music%29#Types_of_chords

As you can see, it has just about every chord you could imagine there. If we did it this way, it would be a BITCH to code. Unless you're a music theory machochist  ;)

So I'm going to suggest this again, just because I don't think I was quite clear enough before:

Have a bank of notes and have the user enter in a number between -24 and +24 (two octives up and two down). Now just sorta sequence those notes whenever a note is played on the controller.

For example, I enter: 1,5,7,5,1 on the arp and whenever I would press C on the controller it would play C,E,G,E,C. And of course you can edit the note length and stuff, how many times to repeat, weather or not to add delay...

I'd really like to get some feedback on this idea. It just seems so blatently obvious that an arpeggiator should do this. This is really the *killer feature* that makes me want to build this, and I know the Waldorf Gecko, the Oberheim Cyclone and the MAM map 1 can't do this. I'm not sure if any other arps can do this.

Other than that, once we get a total feature list, I'd be more than happy to try and figure out where each feature goes in the menu system. Flowcharts and all that... So I guess now our main short-term goal is to actually list all the features it's going to have

[bill]

didn't you see my script ?

http://jambonbill.free.fr/midibox-kb/Arp/chords/

in fact it's pretty simple :

You select a root note, a chord, et voila !

It's easily editable, datas look like this :

"5,8,0,0,0";// Major
"4,8,0,0,0";// Minor
"8,0,0,0,0";// 5
"5,8,11,0,0";// Dominant 7th
"5,8,12,0,0";// Major 7th
"4,8,11,0,0";// Minor 7th
"4,8,12,0,0";// Minor Major 7th
"6,8,0,0,0";// Sus 4
"3,8,0,0,0";// Sus 2
"5,8,10,0,0";// 6
"4,8,10,0,0";// Minor 6
"5,8,11,0,0";// 9
"4,8,11,0,0";// Minor 9
"5,8,12,0,0";// Major 9
"4,8,12,3,0";// Minor Major 9
"5,8,11,3,6";// 11
"4,8,11,3,6";// Minor 11
"5,8,12,3,6";// Major 11
"4,8,12,3,6";// Minor Major 11
"5,8,11,3,10";// 13
"4,8,11,3,10";// Minor 13
"5,8,12,3,10";// Major 13
"4,8,12,3,10";// Minor Major 13
"5,8,3,0,0";// add 9
"4,8,3,0,0";// Minor add 9
"5,8,10,3,0";// 6 add 9
"4,8,10,3,0";// Minor 6 add 9
"5,8,11,6,0";// Dominant 7th add 11
"5,8,12,6,0";// Major 7th add 11
"4,8,11,6,0";// Minor 7th add 11
"4,8,12,6,0";// Minor Major 7th add 11
"5,8,11,10,0";// Dominant 7th add 13
"5,8,12,10,0";// Major 7th add 13
"4,8,11,10,0";// Minor 7th add 13
"4,8,12,10,0";// Minor Major 7th add 13
"5,7,11,0,0";// 7b5
"5,9,11,0,0";// 7#5
"5,8,11,2,0";// 7b9
"5,8,11,4,0";// 7#9
"5,9,11,2,0";// 7#5b9
"4,7,11,0,0";// m7b5
"4,9,11,0,0";// m7#5
"4,8,11,2,0";// m7b9
"5,8,11,3,7";// 9#11
"5,8,11,3,9";// 9b13
"6,8,10,0,0";// 6sus4
"6,8,11,0,0";// 7sus4
"6,8,12,0,0";// Major 7th Sus4
"6,8,11,3,0";// 9sus4
"6,8,12,3,0";// Major 9 Sus4

(it's just to have an idea, please do not use those data's, all values here should be (value-1))

[Martin_Haverland]

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...

Yes that's true generally, but there's also a switch to a more common arp mode when more than one note was triggered directly (preset scale switches to pressed note chord...a bit difficult to explain for me...)

Yep, this scale/chord engine seems to fit this job directly! Thanks - seems i have to wait a bit until it's transscripted to C language (i'm not very familiar with asm). Would make no sense to reinvent a wheel here...

As you mentioned the midibox_master_keys : There's a project on the net that actually does almost exactly what you describe, it's based on a cheap legacy pc on dos with standard midi interface and assembler optimized for lowest latency, please search for 'converter' from urr technologies (freeware). It's concept is reading almost the same than what you planned (and some more i guess). It's great in possibilities and handling and very cool for all kind of midi processing - it is also very useful for analysis and prototyping processing chains, so it might be of use in midibox development, too...http://www.urr.ca/software/software.htm

Kind regards and thanks so far...

Martin

[jrkirkish]

didn't you see my script ?

http://jambonbill.free.fr/midibox-kb/Arp/chords/

in fact it's pretty simple :

You select a root note, a chord, et voila !

It's easily editable, datas look like this :

That's awesome. Blown away. Now just to make everything ergonomic in the user-interface department.

[stryd_one]

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.

It just seems so blatently obvious that an arpeggiator should do this

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...

[jrkirkish]

bump, cause I'd like to know how this project is going.

[Wilba]

Comment about the interface: TK's finding it hard to come up with three letter acronyms for all the new parameters in MB-SID v2... so copying the "step A" interface might not be so good an idea if you're trying to display things like chord names in just three characters.

You might want to start with the "step A" as a base, perhaps increase menu names/parameter names to four characters each (i.e. 2x20 display, four buttons, four menu/parameters per page). This will handle most of your parameters, things like "-128" aren't going to cause trouble. Then for things like chord names which might be better displayed with more than four characters, you could make it span across two items (i.e. over 9 characters) instead.

[stryd_one]

I've been too sick to work on anything this serious, and was waiting on an answer to my last question anyway :) (Whereabouts in the chain the chord and scale generators go - at the beginning or at the end?)

Thx for the advice Wilba! Most chords can be notated in short form and 4 chars would be enough but the scales is a different story ;)

[stryd_one]

Guys? Whereabouts in the chain the chord and scale generators go - at the beginning or at the end? Both?

[TK.]

In MBSEQ V3, I'm using 6 characters to display the chord name:

        ;;               1   2   3   4   <----> (6 chars!)
        CHORD_ENTRY      0,  4,  7, -1, "Maj.I "
        CHORD_ENTRY      4,  7, 12, -1, "Maj.II"
        CHORD_ENTRY      7, 12, 16, -1, "MajIII"
        CHORD_ENTRY      0, -1, -1, -1, "Root  "
        CHORD_ENTRY      4, -1, -1, -1, "3rd   "
        CHORD_ENTRY      7, -1, -1, -1, "5th   "
        CHORD_ENTRY      0,  4, -1, -1, "R.+3rd"
        CHORD_ENTRY      0,  7, -1, -1, "R.+5th"
        CHORD_ENTRY      0,  4,  7,  9, "Maj.6 "
        CHORD_ENTRY      0,  4,  7, 11, "Maj.7 "
        CHORD_ENTRY      0,  4,  7, 12, "Maj.8 "
        CHORD_ENTRY      0,  4,  7, 14, "Maj.9 "
        CHORD_ENTRY      0,  7, 12, 16, "Maj.10"
        CHORD_ENTRY      0,  7, 12, 19, "Maj.12"
        CHORD_ENTRY      0,  5,  7, -1, "Sus.4 "
        CHORD_ENTRY      0,  4,  8, -1, "Maj.+ "
[/code]
Best Regards, Thorsten.

[stryd_one]

Ah right... I'm used to 'M' for major :)

[AbortRetryFail]

Has anyone made a version of this that will slave to an external MIDI clock? I just wanted to check before i go re-inventing the wheel :)

[stryd_one]

I've been working on other projects until the design is finalised.

Which means I dropped this when noone told me what they wanted ;)

[nebula]

I've never really had the pleasure of using an advanced arpeggiator.  I have a few instruments with arpeggiators, and I love to use them, but it always simply arpeggiates the notes played, in some defined order (up, down, order played, random), with the option to add octaves to the range.

Things I've always wished for:

- rhythmic variance

- why must that range enhancement be octaves?  certainly nice results could be realized with other intervals

- option to always reset the pattern after n steps - because sometimes you want to clip the arpeggiator-generated phrase to a bar, or some other musical value

- option to quantize my sloppily played chord right to the beat of the song (i know this would probably be tricky)

- ability to change the rhythm - this could be done by delaying and/or muting steps

- ability to change the musical passage.

for the musical passage, i envision this:

typical arpeggiators allow the addition of octaves to the note set.  imagine doing away with this mentality for a moment and replacing the "octave" enhancement with simple "varation units", which i call "mutants".  each mutant has a list of notes , mathematically related to the notes currently held at input.  let's say the arpeggiator has (for the sake of argument) 6 mutants.  each mutant could also have arpeggiator parameters unto itself.

 

going back to our "octaves" for a second: if you wanted to achieve a simple arpeggiator that adds notes 1, 2, and 3 octaves up, you would set mutant a, b, and c to +12, +24 and +36 respectively.  you would then set the unit to play the entire note list being held down, then play mutant a's note list, then mutant b's note list, and mutant c's note list, all in 8th notes.

for something (slightly) more interesting, let's try a simple setup with our base arpeggio and 2 mutants.  the base is set to arpeggiate "up", mutant a is set to arpeggiate "down" at +7, and mutant b arpeggiates "up" at +12.  if we play a C-Maj triad we'd get this:

[pre]

C  E  G  D^ B  G  C^ E^ G^ (notes with a ^ are an octave higher)

[/pre]

another editable parameter might be how quickly, rhythmically, we move from mutant to mutant.  so let's fix the base at 4 steps, mutant a at 2 steps, and mutant b at 2 steps.  Then you'd get:

[pre]

C  E  G  C  D^ B  C^ E^

[/pre]

Continuing with this, set mutant B to play at 16th notes, and you'd get this:

[pre]

C  E  G  C  D^ B  G  D^ C^ E^

[/PRE]

(except that the D-B-G-D phrase would be 16th notes)

... to summarize:

- a base arpeggiator

- a number of "mutants", each with their own set of arpeggiator parameters and a mathematical (and/or musical scale-based) relationship to the base

- a simple, event-driven sequencer that selects between the base and any mutants for a predefined period (in musical and/or logical values)

a hardware UI for this would probably have a button to select each of the above (base arpeggiator, each mutant, master sequence).  a good-sized display with soft keys could probably show all parameters for any mutant.  choose the parameter with a soft key and adjust up or down.

...

please understand that this is me dreaming of an arpeggiator that i'd like to have, and since this thread is an open invitation to share, i'm doing exactly that.  i am not requesting or presuming anything.

so when will it be ready, stryd?  ;D

[Jaicen]

At the risk of repeating stuff already said, I thought i'd add my tuppence to this thread.

I've actually just had the pleasure of working with a Juno 6, which posseses a damn fine arpeggiator if you ask me. I like that you can set it very fast to sound like a C64, which is cool, but not where i'm going with this necessarily!

I actually wanted to talk about an epiphany I had. I plugged in my DR-110, to sync the arpeg to 16ths along with the beat. However, on some of the demo beats (C1 for example, DR owners ;) ), accent isn't applied every 16th note, rather it's a pattern. When I sync the arpeg to that, it produces some very very cool patterns.

So, I was thinking that a stand alone arpeg could have a multiplier for MIDI tempo (1x, 2x etc), and also be programmable like the MBSID, so you can choose to have 'missing' 16ths, if that makes sense. That's pretty much all I wanted to say really. I'm off to design a discrete seq based on a PIC and a decade counter ;)

[nebula]

Why would you need a decade counter if you've got a PIC?

[Jaicen]

The PIC is for converting MIDI to DIN sync, and also divided clock outputs (ie, 48ppqn, down to 1/16ppqn). The PIC generates the clock signal, and the decade counters basically select note on or off per 16th note.