stryd_one

Hah it's a bit like that on any planet inhabited by homo erectus. If I'm unfortunate enough to be around post armageddon I'll be stretching goatskins over wood. I learn from my mistakes ;) I was thinking though... If the turntable has enough room to reach the back and mount a record, the laptop would have a fair bit of separation - is the magnetic field still effective at that height? Might be worth trying smash's trick ...

I'm pretty sure I've seen them... Yep I got the name right, they're referred to as PCI riser cards. Google gets me this http://www.mini-itx.com/store/?c=8 flexible cable which should be fine, and there are also ones with multiple slots from one, but you might want to make sure these will actually work with your mobo. Beaten hhehehe Edit: http://www.tmc-uk.com/supports/general_faqs/riser_card.htm good info :)

Que?! :D

I'm with smash on that one hehehehe I'll do that post justice and read it after some work I gotta do, when I can pay full attention.. In the meantime, more pretty pictures. Accuracy of 22/7 over 10000 steps maxes out at 0.987, still within 1 master tick but pushing it's luck as the primes tend to do when divided ;) Naturally the error's growth is inverse exponential so it is still .987 at a couple hundred cycles. The second one is two cycles, to illustrate it's tendency to restrict itself from spiralling out forever, which it looks like it'll do in that first pic. Ain't it great to see the way each spiral gives birth to a new one when it is killed. I love mathematics, truly the stuff of life. :) dist227.GIF dist2272.GIF

Ahhhh.... The 4620 has a bug in the serial peripheral which means that MIDI can get scrambled. This EUSART bug means that the IIC_MIDI module is a must! If you check this page IIC MIDI Module and search for the part about "Default Tx Redirection" you will notice that you need to have the correct ID to use it by default. What ID did you select when buying from Smash? I'm a little concerned about the screen not working though... Might want to revisit that one once the MIDI interface is sorted, maybe uploading MIOS with the dodgy midi has busted the chip up, it might need to have MIOS uploaded again.

Make your own DCB-MIDI convertor mate :)

Yeh I've been eyeing those off as a first electronics project for my g/f. It's as much for my benefit as hers, I just think they sound cool ;) heheheh I bet she does ;)

Ah we like when that happens :) Thanks for doing the troubleshooting, those displays are quite common, so it's nice to have a documented note about their power requirements in the MBHP.

Actually the prototype is a bit different now, I have to convert the new documentation to wiki format so maybe check the link in the next few days :) Sorry for the poor timing! I'll post here when I update the wiki. I should mention something I forgot in my FBAP, the vX does it's calculations in 96ppqn ticks for better accuracy... I just did the examples in 24ppqn because it's nicer to read and the numbers are easy to understand :) Mike thanks for your kind words and especially your analysis ; I'm just a hobbyist at these things and I've been secretly lacking confidence that my solution was optimal, so it's nice to have that double-check, and it sounds as though it's the voice of experience :) I thought the same thing about the lookup tables when I saw the patterns, but there's a couple of catches... Because of my desire to dispose of linearity, there is no song counter which can be used as a reference. That's one of the bonuses of the algorithm, it operates in a way that allows it to stay in sync with other clocks without any awareness of it's relation to them or the 96ppqn master clock. There is the option of storing the rounding patterns (like 'up up down repeat', for 9 steps/bar) but the table ends up being very large to support all the different possibilities, and it also means that the time taken to calculate the next step will vary, meaning the timing could be unpredictable... On a happy note, the scale engine from seqv3 is sure to be "borrowed" for the vX (which reminds me I need to finish off the tables this weekend!) so gamelan dreams await :) With full credit to TK, of course! Stuffed if I can find that Ardley album though :(

lmfao, the exact thing i thought!

Oooh a new section in the forum! I thought I should honour the occasion in some way so I thought I might share some of the research that I did for the subclocks in the vX. I'll try and make this make as much sense as possible and include lots of pretty pictures ;) So here's the idea. I want to be able to run a group of clocks, which will be synchronised with each other in some way, but will trigger different numbers of steps per bar, like this: :|x x x x |x x x x |: 8 steps/2 bars :|x x x |x x x |: 6 steps/2 bars The reason behind this is to have a sequencer which will allow the use of polyrhythms, which are widely used in ethnic music and the only way to play breakbeats in their original form (before western notation got involved and the boffins decided to make it fit into their existing timing scheme). If you're not sure what I mean, find some old "taiko" (sometimes called "daiko") drums and be introduced to my favourite form of music :) Polyrhythms are enjoying something of a resurgence in some forms of music in the last few years too (especially in industrial electronica and rock), and I suspect that we'll hear them on the charts before too long ::) So, how to go about this? .... Most of the time, a sequencer will count down a certain number of MIDI clock ticks before triggering the next step. Because MIDI clock ticks at a rate of 24 ticks per quarter note, for example, If you want 1/4 notes, you wait for 24 ticks between each step. For 1/16th notes, you want 1/4 of that time, so you wait for 6 ticks to pass before triggering the step. For a 1/4 note triplet, you would want to trigger 3 times every 1/4 note, so that's 3 times every 24 ticks, so 8 ticks. If you want a whole note (one bar long) then you would wait for four 1/4 notes, 96 ticks, to pass between each step. It may be becoming clear to you now why the number 24ppqn was selected - at 96 ticks per whole note, it makes it simple to find commonly used measures of time in modern music, such as 1/2, 1/3, 1/4, 1/6, 1/8, 1/12, 1/16, 1/32 etc etc etc. If you take 96 (ticks) and divide it by any of those numbers, you will find that you get an integer (no decimal point). Awesome. So what if I want to hear 5 steps per bar? This is not the same as 5/4 time, which would be 5 of the 24ppqn ticks - I'm talking about 5 steps in a normal 96 tick bar. If we divide 96 by 5, we get 19.2. Houston, we have a problem. There's no such thing as 0.2 of a tick, and the countdown to the next step is measured in ticks. 0.2 of a tick is empty space between the ticks themselves. How would we know when to trigger the step? Now, if we want to hear 5 steps per bar, we could wait for 19 MIDI clocks to tick between each step. But of course this means that after 5 steps, only 95 ticks have passed. This means that the next bar would start one tick before a normal length bar of 96 ticks would. And the next time it would start two ticks too soon, then 3, and 4, and before you know it, the bar is a 1/16th note out of sync with the rest of the song, and getting worse by the moment. No good. Alternately, we could wait for 20 ticks each step, but then we get the opposite problem, and the same result - it's out of sync. The trick here is to remember that music is ALL about fractions (ratios, if you like) and fractions don't use decimal points, they use a "remainder" or "modulus". So 1/5 of 96 is 19 with a remainder of 1. The remainder of any combination will be the amount of 'drift' in synchronisation explained just above. So, no problem. All we need to do is tack the remainder onto the end of the bar. So 5 steps will be triggered, each with 19 ticks between them, and when that is over(95 yicks have passed), we wait 1 more tick (the remainder), before starting over. Obviously, it is not perfect, but it is as close as possible with the master clock (24ppqn) that we have. The first note will begin at the correct time, and the notes will be 0.2 of a tick too soon each time, until the last tick, where the remainder is added on, and that note is a little longer (19(normal length)+1(remainder)), to compensate for the others being a little too short. This error of 1 clock tick is not really much, and is pretty much acceptable. Humans have drifted more than this for centuries and nobody complained ;) Yay a solution! Bzzzt wrong. There are two problems with this idea. If this 1/5 note clock is started at the same time as a normal 1/4 note clock, then they will both start together and end together. Fine. But if they were started at different times, the remainder may get tacked onto the end of the 5 notes, but that might be played in the middle of a synchronised 4 note bar. In this case, the error is not really increased beyond that described above, so it is still a deviation of 1 tick, as good as we can get....but we should consider... What if our remainder is bigger? For eg, What if we are talking about 9 steps per bar? (10.6 recurring ticks per step) Now we have 10 ticks per step, for 9 steps, which leaves us with a remainder of 6 ticks. it would look like this: Step ticks 1 10 2 10 3 10 4 10 6 10 7 10 8 10 9 16! (that's 10, plus the remainder of 6) Yuck! Imagine that big long step sitting in the middle of a nice neat 4/4 bar.... and the maximum error is now quite large too, because even after two steps there should be 21.333 ticks, we're already over one whole tick out of sync. after 3 steps, there should be 32 steps but there have only been 30, now we're two ticks out of sync. And it just get's worse and worse until we are finally 6 ticks out of sync. Bad. What we want, is to slowly smooth this remainder out over time. In the chart below, we can see a way of doing this with floating point calculations, just for the purpose of illustration, again using 5 steps per bar. The floating point calculation is on the right hand side. It shows how many ticks would pass to divide the bar up evenly. The next column from the right shows the floating point number rounded to the nearest integer. the 'ticks' column shows the number of ticks inbetween those integer figures. Step ticks FP, rounded ticks (floating point - the ultimate and impossible goal) 1 11* 11 10.6` 2 10 21 21.3` 3 11* 32 32 4 11* 43 42.6` 5 10 53 53.3` 6 11* 64 64 7 11* 75 74.6` 8 10 85 85.3` 9 11* 96 96 Remember that our gap between steps was 10, with a remainder of 6? Notice that sometimes, if we round to the nearest whole number of ticks, we need to add 1 tick to the normal gap of 10 ticks. Notice that in one whole loop, that happens 6 times? That's our remainder, and if you look at the chart above, you can see that it is not just 'glued' onto the end of the bar, but nice and neatly distributed throughout the loop. MMM, pretty. Now, that is all well and good, but as you may be aware, floating point divisions are very processor intensive. If we calculated the countdown between steps like that, well, it just couldn't be done . So my theory was, that the distribution of the remainder, was directly related to the value of the remainder and quotient. And sure enough, it is. I just needed to find a computationally inexpensive method of calculating when to add a tick from the remainder, and when to not - Or looking at it from a floating point perspective, when to round up, and when to round down. And I need to do it by addition and subtraction and maybe multiplication, but definitely not dividing. So I came up with this method of modulus distribution. I'll continue with the example of 9 steps per 96 tick bar. When the clock is first initialised, there is a divide operation. This is the only occasion where a divide is required. This returns the quotient and modulus of the equation. (eg for 9 steps, the quotient is 10 ticks, and the modulus (remainder) is 6 ticks). There is a variable used to count down to the next step, and the trick is, a 'modulus counter' variable. Here's how it is used. When the clock is initialised, modulus counter is set to the modulus (6). ... the countdown until the next step is set to the quotient (10) To calculate the length of the next countdown, the modulus (6) is added to the modulus counter (now=12). If the modulus counter (12) is greater than the modulus (6)(it is), then 1 tick is added to the countdown (now=11), and then the quotient (10) is subtracted from the modulus counter (now=2) The countdown is decremented each time a midi clock event is received When the countdown reaches 0, the next step is triggered, and this process is repeated.... the countdown until the next step is set to the quotient (10) To calculate the length of the next countdown, the modulus (6) is added to the modulus counter (now=8). If the modulus counter ( 8 ) is greater than the modulus (6)(it is), then 1 tick is added to the countdown (now=11), and then the quotient (10) is subtracted from the modulus counter (now= -2) The countdown is decremented each time a midi clock event is received When the countdown reaches 0, the next step is triggered, and this process is repeated.... the countdown until the next step is set to the quotient (10) To calculate the length of the next countdown, the modulus (6) is added to the modulus counter (now=4). the modulus counter (4) is not greater than the modulus (6), so the countdown is left alone (still = 10), and the modulus counter is left alone (still=4) The countdown is decremented each time a midi clock event is received When the countdown reaches 0, the next step is triggered, and this process is repeated.... And if you can actually make sense of that mess you may have noticed that there is a pattern formed - it goes 11, 11, 10, 11, 11, 10, ..... Just like the rounded floating point calculations! Yeehah! This all sounds more complex than it is.... it comes down to a matter of a few instructions each time a new step is triggered. Anyway I promised pretty pictures, and of course I had to test the algorithm out to see how it would work and how accurate it would be, and it's resulted in a big excel document with a couple of graphs. The first one is a graph of a chart like the one above, with the floating point calculations compared to the vX algorithm. It's extremely boring, just two straight lines. That's actually a very good thing, because I don't think you'd be able to tell them apart without the index: Boring. But nice to know. I've also graphed the deviation from the perfect result. To make sense of this, if the points ever reached the edge, they would be going beyond a whole tick out of sync, but so long as they are within the circle, we are as accurate as it is possible to be. Points at the center are perfect. But the reason for this type of graph is to demonstrate the rhythmic nature and even spread of the modulus. The end result is a flower. Oh how nice. I have attached the graphs for a 9 step bar over 1 and 4 bars. The more complex the subclock timing, the more interesting patterns come out of this as the algorithm struggles for perfection. Prime division makes for really interesting neverending flowers, and I included a 63 steps per 15 bar pattern graph just for kicks. Hope you like the happysnaps and the gory details :D I'll follow up with more detail (this was a simplified explanation) and some posts on the rest of the sequencer as time goes on... accuracy.GIF dist9step.GIF dist36step.GIF dist6315.GIF

"Nice" is just one word I would use :) The special service TOS implementation especially, is very nice indeed, and the CS immediately springs to mind. I love the way you've done it, and just like with the C interface I think that you've made good functionality very easily accessible for us mortals :) Awesome :D Uhm... just to make sure I am not confused, that's 60 kilobytes per second isn't it? That sounds too fast, but I keep checking my math and either it really is that fast, or I had an even worse day than I thought LOL Kbps,kBps,KBps,kbps,KBPS oh I don't know any more :P Edit: I had to google to make sure I'm not going mad. http://web.forret.com/tools/bandwidth.asp?speed=31.25&unit=Kbps&title=MIDI :) I'm still sane! (arguably) I like the way you think ;D

That sounds like not enough power, maybe it's locking up... either that or a short that only takes effect when the LCD is connected... I'd maybe double-check my soldering and connections and then try more power. What's the power rating at the moment?

Hmm, if it seems to be working OK but just showing the wrong characters*, then it's probably the wiring to the core. Check it again, but only use the schematics, just to be sure.... *You can check this by hitting menu buttons etc, and see if the screen changes.

LOL Too true! Good luck with it!

LOL hang in there man.

Cheap magnetic strips for ribbon controllers perhaps?

Uh oh Hmm you'd want 9 DOUT and 32 DIN.... can you split it up and do 18x16? You'll need to extend the scanning matrix example a bit, but you may like to take QBAS' keyboard driver as an example... Unfortunately more than just main.c, there's some ASM coding involved. I'll help as much as I can and the forum is here chock full of love as always hehehe

I stand corrected :)

I don't mean to detract from LX's excellent work, but I thought I should say, that such neat cabling is just a case of measuring things properly. It's entirely believable that such a thing could be a first project, it just take a perfectionist, and a lot of time :)

Post a picture mate :) I know it's a bit OT but one or two OT posts won't hurt... It's kinda in context... Kinda.... OK I admit, I just wanna see it :)

:o ;D 8) :) :-* :-* :-* :-* ;) I think this might be the biggest midibox news in years. Huge. Thanks again for all your work TK. I'm all excited I feel like a kid in a candy store!! Sorry, but someone will do it sooner or later, so I have to be the first to ask... How fast is it in real-world applications? ;) We know CAN will do 1MB/s but obviously there are other limitations, especially the resources on the PIC (no point pushing around huge chunks of data if the PIC has no cycles left to process it)... Surely there are other considerations, I hope you wouldn't mind telling us some more. But maybe take a break and admire the fruits of your labour first :) Now all I need is a smoke while I read that page thoroughly and my paypal password for that little button up there ;)

:( Sorry to hear it, and thx for the advice man. Hope the matrix treats you better!

Let's see... Time required to do this: Months. Let's say 300 hours (that's 2 months full time). Money required to build separate boxes: Lets say $600 (they'd be fairly nice at that price) So if you earn more than $2 an hour it's a waste of time. Obviously those figures might change a bit but you get the picture... But don't let my pessimism stop ya! ;) Personally, I'd mount the PIC in a ZIF socket either accessible from the outside (front?) of the casing or in some kind of cartridge, and change pics over instead.

Keep searching mate, I'm pretty sure all these questions have been answered :)