stryd_one

Search for FPAA :)

Thanks Thomas. Maybe that's what TK meant when he spoke of the poor performance with arrays... although adding an extra dimension to the array I guess it makes sense that the code size increases, but now we know exactly why it's best avoided....

Sounds like a short... might be worth (re)checking solder joints and fixing up that meter? What happens to the LCD's if you leave off all those loose switches (or just the whole DIN)?

So I had a look around and I think this PDF explains it to a fair extent: http://cslibrary.stanford.edu/103/ ? I see what you mean about the sequential vs random access... I think this method is well suited to a traditional sequencer because of this, and also because it seems simple to add records into the list, but I think it probably wouldn't work too well in my case because the way my seq works, random read and writes would be pretty common, as it's not necessarily linear in the way it plays...Also, the sequence will have a fixed structure, all the steps of all the tracks should be available at all times, and just filled with 0's if they're not in use, so there wouldn't be a need to add or remove records from the list. While I think of it, I should mention that I might need to treat some of the data as bitfields. I don't know if that would effect things or not. Just when I thought it was going to be easy huh? :-\

curiouser and curiouser :) I'ma go and google this so I'm well prepared for your explanation, thanks again OG.

This is really good stuff...and hey OG, I like verbose :) Heheheh you guys keep posting new stuff before I can post my reply...This is my third attempt ;D It does make me wonder the best way to go about storing the variables for a sequence though.... The pointer math method seems more like the ASM way of doing things, but obviously isn't highly recommended in C ;) ... Multidimensional arrays seem CPU and possibly memory hungry. I know that there would be a fixed number of steps per track (16) and a fixed number of parameters per step (let's say 4). I was thinking that a structure and a one dimensional array could work if you had something like this: step[n].Param1 step[n].Param2 step[n].Param3 step[n].Param4 But that would leave me with a maximum of 256 entries which means only 16 tracks of 16 steps (not enough) With all the knowledge going on in this thread I thought I would be silly not to ask for more of your advice, I hope you don't mind.

I've been reading this online book and thought that it might be handy to other C n00bs like myself ;) It describes C in a fair amount of detail which is great, but the thing that I find makes it really special is that it is also very easy on those not familiar with C. I suspect it'd be good if you have no programming experience at all too. http://publications.gbdirect.co.uk/c_book/ Hope you find it useful stryd_one

That's no vocoder! A vocoder sounds similar, but is an effect where, for example, a human vocal is mixed* with a synthesised tone. That MP3 is synthesised speech - no human voice involved :) *Edit: I don't mean mixed as in VCA mixed, but you can google it and find out how it's done ;)

Thanks for that OG :) I just realised that my post got kinda screwed up... It was meant to look like this: my_array [x] [y] [z] But I suspect that the theory is similar, the first (3-D) array points to the second (2-D array), points to the third (normal) array. So the questions now are, does SDCC compile multidimentional arrays, and would the performance be effected? I'll find out the answer to the first q easily, but I have no idea about the other?

I'm betting that'd be one helluva ugly box ;)

Hey MIDIBoxers, Forgive me if this is a silly question or already answered but... Can we use multidimensional arrays? as in: <code> my_array [8] [8] [16] </code> Would be really handy for a sequencer like this... <code> Step_Param_Value [Track] [step] [Param] </code> I must admit, once you get the hang of it, C can be so nice and pretty to work with.... If something like this could work it would be awesome. But then it raises the question - is C the best tool for the job? I think TK mentioned something about SDCC not performing well with arrays?

*scratches his head* is DOUT_SR_NUM really defined as 4 ? Maybe see if hardcoding some of it helps? I'm puzzled...

Thanks David :)

Awesome, glad it's sorted and can't wait to see the pics!

Thanks Meeshka!

That'd make it pretty useless unless it was the first device in the chain, which is pretty rare for a sequencer :( Honestly I can't remember why, but if I rightly remember the SM driver runs in an interrupt which could cause timing issues...? TK would be able to advise better on this. I could be totally wrong!

Shame I need a couple hundred :( Keep 'em coming mate :)

TK you're priceless mate ;)

MBSEQ V3? ;D You're just going to drop that bomb and tell me nothing, leaving me in suspense, aren't you? ;) heheheh

The core will support the 96 inputs but your application may not.

I got your point, you got your answer....

I'm sorry that I can't answer your question but it does leave me wondering... Why would you bother?

This seemed like a good idea to me too, until I saw the price of the PLG cards, ouch.... Might as well just spent $100 more and get a keyboard/module to hold the other cards.

What if they're not 16 steps long? How do you avoid loops? BTW the scanning matrix driver doesn't behave too well with the MBSEQ design... It will need to be on a 2nd core due to timing issues

I know what you're asking. I don't think you understand enough about the question you are asking, which is proved by saying this: How do you think the USB MIDI is converted to normal MIDI? Magic? You HAVE to use a computer!! That computer could be an embedded system like a MIDIBox, or a dedicated PC. I told you how it would be possible on a dedicated PC. The theory is the same with a MIDIBox - but I don't know that much about MIDI over USB, so I don't know if the MBHP USB module is suitable for using as a USB MIDI input, which can then be routed to the standard MIDI output. I hope you understand.