vX

[stryd_one]

http://sourceforge.net/tracker/index.php?func=detail&aid=1692042&group_id=599&atid=100599

Worst. Bug Report. Ever.  ;)

[audiocommander]

hmm,  :-\

maybe it would be easier to respect the 255 byte maximum and all that cryptic linker stuff and split everything into smaller chunks: wouldn't that be possible?

just a guess, though...

(glad I sticked to my 2.5.4 sdcc version, btw :) )

cheers,

Michael

[stryd_one]

I wanna outright disrespect that damn 255b limit, I'm gonna smack it in the face >:( hehehehe

I could maybe have a separate array for each track but it's gonna make code large and difficult I think...

I'm also stuck figuring out precedence of the note off buffers, as in, which one of the buffers should be emptied early, if all the buffers are full. Do I do first in, last in, shortest time remaining (could be hard to keep track of)...Any thoughts?

:'( woe is me.

[stryd_one]

http://sourceforge.net/tracker/index.php?func=detail&aid=1692042&group_id=599&atid=100599

Worst. Bug Report. Ever.  ;)

Date: 2007-04-01 21:07

Sender: borutrProject Admin

Logged In: YES

user_id=568035

Originator: NO

fixed in SVN revision #4731.

Borut

17 hours! Fixed! :D

[stryd_one]

Now that I've sorted the big banks issue I thought I might mention an idea I had... Nonlinear clocks.

Basically instead of going like this

x.......x.......x.......x.......x.......x.......

We could have this

x.........x.......x.....x...x...x.

or this

x..............x.......x...x.x.x...x......x...............x

or this

x.x..x....x........x................x........x....x..x.x

etc etc.

Now of course this is a clock, so the calculation of the gaps (...) between triggers (x) needs to be fast.  Bitshifts instantly come to mind, and I was thinking about combining bitshifts with addition and subtraction, anyone have any ideas?

[TheAncientOne]

There is a phenomena in software design known as 'Feature creep'. You just get the main code running, when the system specifiers, or more usually the people in marketing, come in with a new feature they've just thought of and is now a vital part of the spec.

There are certain well known historical projects that never ran because of this. In fact, I think one well known 'solutions house' extracted an immense amount of money from the UK government by allowing the spec of the software to creep out of range of the hardware capabilities, then getting the project cancelled without ever handing over any hardware or software.....

The antidote is 'Design Freeze'. Decide on the spec you want, that is feasible now. Lock yourself in to that, and get it running. You'll get far more feedback on the spec for Version 2 this way, and have something to play with.

It's a cool idea, but if it were my project, I'd be looking at a feeze point around now. When you do V2, you can add in your new ideas, and probably do a clean re-write, which will incorporate all you've learned so far. You'll end up a slicker fuller featured machine, but with leaner code. You'll also learn what seemed like a good idea, but never got used, and so can be left out.

Believe me I've been there: I wrote a sequencer running on a BBC micro that got too bloated to hold any decent length of sequence. I was a bit like those car customizers that don't know when to stop adding twiddly chrome bits and blue lights. I never used the final thing much.

Mike

[stryd_one]

a bit like those car customizers that don't know when to stop adding twiddly chrome bits and blue lights.

LOL :D Ta for the advice mate. It is a kinda old concept and the implementation of a few types is already figured out, but I just haven't mentioned it before. It's funny though, because I have all these scrapbooks that I write ideas in, and I think that's the only one that never got written down. I just kept remembering it at inconvenient times, until yesterday when I sent that post. It's got spooky karma... I'm leaving it till later, as it seems it wishes ;)

[audiocommander]

Now that I've sorted the big banks issue I thought I might mention an idea I had... Nonlinear clocks.

Basically instead of going like this

x.......x.......x.......x.......x.......x.......

We could have this

x.........x.......x.....x...x...x.

This is a great idea!

Remember exploding brains, when we discussed buffering techniques?

Now, it's stunning, that I came to the point working totally without buffers for the next sensorizer; actions just get triggered by clocks. So if it's not the right time, nothing happens. Well, I guess this principle is not really extendable to other projects, but I cannot believe how long I thought about complex buffers before this strikingly simple idea hit me.

Now you're talking of nonlinear clocks and I feel there is something similar going on that is definitely worth exploring :)

I wouldn't freeze any idea while being in development status. Normally some features get dropped before release 'cause they don't work anyway, so why restrict your imagination now? You're no company, you have no customers and if someone elses hobby-vX is exploding in experimental mode it's not really your problem (is it? ;D )

It sounds like a simple idea with extreme effects. And I like simple ideas with great impact very much.

Cheers,

Michael

[stryd_one]

I'm glad you like the concept. The app is pretty close to supporting it already, the tricky part is coming up with useful mathematics to determine the length of the clock ticks... Like you might start with 96 ticks to count between ticks, then after it ticks, shift it right and increment a counter, repeat until the counter reaches n, then start over.

The code for the subclocks probably could do with some optimisation, but they do work, if you want to borrow for the sensorizer shout out :)

[stryd_one]

;D F@*&'n eh baby, I am one excited MF right now. OK so I now have what I consider to be the first working alpha build (v0.1 Build 48 heheh). It's verrry raw, but has 4 subclocks fully working, with twin patchbay routing to tracks, to play a step or increment to the next step, on one of two tracks  each with 16 steps,(it's only on a 452 right now, a 4620 will improve that somewhat. It's fully expandable, once I get it on a 4620, even without the sram it will have enough to carry around 12 tracks and 6 subclocks and all I need to do is change a couple of defines.) Note offs are working, relative note numbers are working, the event engine is working including manually buffered recursion and function priority (so that modifiers on tracks will work before the previous tracks play midi data)

BTW moogah, this means that your request for an "if this happens then do this" capability is now implemented. I always wanted the feature and when you asked for it, I had to find a way. The end result is that the majority of the operation of the sequencer is run in this manner. I'm really glad that I did this now, as it made the design more modular.

There is no user interface to speak of, all the values for the sequence are initialised and can be changed once I hook something in, but at the mo, it's just hardcoded sequences and a start button implemented by a midi note heheheh.

I need to make fairly major changes to the structure of the data storage, both to improve performance and to prepare for the SRAM extension, where only the next data needed from each module will be stored in PIC RAM and it will be pre-read as required.

I also need to pass the clocking and track stepping functions into the event engine so that those events will be able to trigger events in other modules, basically meaning that you can syncronise track and subclock start points and such.

So yeh, there is lots left to do, but the sequences can be hardcoded and played. I just made a contrapuntal 16:11 polyrhythm, a thing where one track modulated the current step or the start and end steps on the other track, and a weird thing with a 1/16 clock and a 1/5 clock, patched to two tracks like this:

            play step  advance to next step

Clock A  track 1    track 2

Clock B  track 2    track 1

And track 2 playing in reverse just cause I wanted to hear something weird.

So you guys who wanted to hear a demo, what do you want to hear? Remember, only 4 clocks and 2 tracks for now...

[audiocommander]

So you guys (...) what do you want to hear?

yeh baby! give us some F@*&'n funky tribal subclocked polygroooves!

[dj3nk]

What we want ? I want a 3 against 4 polyrhytm. Basedrum with percussion.

Cant wait to hear ^^

greetz

Is the song roxanne polyrhytm ?

[stryd_one]

ohh 3 against 4 is boring, you can do that with triplets  :) I'll do that and 5:4 just for kicks :)

Nah roxanne is straight 4/4...

[stryd_one]

there are so much other ideas to mangle midi data

why not implement a sort of korgs KARMA  or things from the LATRONIC NOTRON sequencer.

That's the job of my seq ;)

I'll release details soon...

[puddingbrumsel]

That's the job of my seq ;)

I'll release details soon...

:o niiiiceeee!!!! I'm very interested :D

[stryd_one]

Hahaha damn, I was just coming back to edit that post, because I rushed it (posting from work == eating lunch while editing code and replying to midibox and answering phone calls. I should stop that.) and it sounded rude when I saw it later. Beaten! LOL

I'd very much like to see that kind of thing in the mbseq (as well as your previous suggestions which would be awesome), but you may not be aware of TKs FILO list ;) Seeing as I'm covering that 'weird algorithmic sh**' thing off, it leaves room in the 'buffer' to do some of the more requested features, which is why I suggested my project.... aaand I'd completely forgotten, I've already taken down the old page while I'm nameing the new one, so you probably don't know WTF I'm talking about LOL.

I just killed the SNR, so I'm gonna split this post off.

[stryd_one]

That's better ;)

Probably should post an update instead of black hat discussions in the chat room and such... It's been like..a while. Chatroom dudes can just ignore this post, you've probably heard it all :)

I'll try ad keep it brief. Well I wanted to push this thing a bit harder than I had been, and it just didn't want to play. If I got the sequencer to behave itself with a number of tracks that was even remotely useful (using external RAM), midi went berserk if I tried to send it controls. And that was with a 2-button CS. It was just asking too much of the PIC. I hit similar roadblocks in the past, and had considered things like dual/multiple PICs with parallel or CAN communications, but I'd put it in the too-hard basket. This time I came up with a variation that I thought might just work... Sharing access to shared external SRAM to two PICs. So I tinkered and played and fried a 628128, discovered a handy bus arbiter chip, and eventually come up with something that, shock horror, actually worked. I've got schems and boards in kicad format (and images) a MIOS driver module (ASM and native C - I think it's the only native C driver around) here if anyone's curious. Actually I'll attach some pix.

So yeh, it worked, at least it would allow one PIC to write a bunch of data to ram, and the other to read it, without any nasty collisions. But, I never did get around to adapting the code to use it, because TK announced his intentions regarding SeqV4 (that's gonna be a MONSTER) and it's basis in the new core. I've had a lot of fun and learned a LOT of stuff doing the vX so far, but... I'm not crazy. This core is clearly the smart move.

Fortunately, I had been secretly hoping that this new core would come some day soon, and so I have been writing my code with this in mind. hehehe. There's not much there that's PIC-specific, it's all C, so it should work OK with the new platform. That is, things like the sequencer and LFO modules and signal handlers will only need minor changes.

That said, I don't particularly like the idea of just porting it across. Why? Well heck, if I'd been using a 32bit micro to start with, it wouldn't be designed like it is. This thing has just undergone too many overhauls to try and make it work on a PIC, it's not the sequencer it once was. (note: this paragraph confirms TK and TheProf's prophecies. I knew they were right....Why did I do that...) Even the original concept I shared here was watered down a bit from what I really wanted, in that it was semi-modular both in routing and in modules. Fixing things like that, made for faster handling, but it also made for greater complexity in code. Seems strange to spend so much effort to make the machine less capable ;)

So what this is coming to, is that I've been doing some homework and I'm pretty damned sure I can make this fully modular on the new core. The modules are already ready for it, it's just a matter of doing the routing. A helping hand from nILS has me on the right track for this.

I'll fire up some doco, which I'll need myself, and share it here soon. In the meantime, here's the promised pic from times past: