stryd_one

Oh no!!  :-\ I went to gather all the information that I had saved in my private message outbox on this forum for the designs of my sequencer... And there's nothing there :'( :'( :'( Anything I can do, or is all lost? Thanks

Cool!! :D Thankyou for the video! (Merci!) This is a great idea. This is working now? Or still jumping notes? Let me know if I can help.

Yeh those have been in my watch list with some other parts for a day or two now... If anyone from this board is bidding then please let me know, I don't want to compete with a friend in auction :) PS I'm in Victoria where these are being sold

If the notes seem erratic and the pads are definitely not triggering erratically then you might need to look at the code that is handling how the triggers send MIDI, although if you are using TK's code as designed then I am sure that the code is OK. I see you have a set of LED's assigned to the pads, do they light up as expected, or do they jump around like the MIDI notes do?

Yes, please share this with us! :)

404 I'm not any more! :)

What an awesome idea! I'm not much for electronics stuff like voltages so I don't know if I can help with your question, but I'm not so bad with programming, so I wanted to offer my support in your project, should you need it - it's a really clever idea!

Careful, Keyboard cables are not shielded :(

I'm already way on top of this ... But it's gonna take ages, so be patient :) I'm sad to say, that it's not nearly as simple as you appear to think. Using a PIC other than the 18 would just be using a less powerful chip, so that doesn't help at all - we already need more processing power than one PIC18 can provide (the current project with the seq is communications between 2 or more cores). A set of 512k banksticks will be used for RAM, and that's probably enough to hold at least one tune (4M). 4 others from this board (including TK, of course!) and myself have been working on the new firmware, and concepts for it, for about a year now.... Relatively easy? I think not! ;D But it'll take more than that to stop us!

Yeh count me in :) Obviously I'm kinda busy with the sequencer now but this sounds interesting so I'd like to offer my help where I can Cheers

:D Sounds rad TK!!! You never cease to impress and inspire me!

Heya TK Man, a parallel interface would be GREAT! I looked at that, but gave up on the idea as I wasn't sure how to mesh it with existing MIOS functions... Sounds like you already took care of that! I'd love to check out the application for this... You can email it to me if you like, I'll PM you my address now. Thanks again :) PS I like that "gadgets" idea too, it's got me to thinking..... :)

Seeing as Duggle is doing university exams at the moment, I think I will not bother him too much with this right now... He will be back in a month, so we should all wish him good luck in his exams in the meantime. Go Duggle! :) I've found lots of information regarding PIC IIC slave operation, but almost all of it uses the on-chip IIC support through the SSP module, which isn't available in our case... I wonder how hard it would be to use the hardware IIC support? It looks like the SCL line for IIC is being used as the clock for the shift registers with the current design, so without any buttons/faders maybe it would be possible? If it's not possible to use the SSP module, then it appears that the only way to implement a IIC slave would be software polling of the pins, which could take a lot of cycles (or maybe not... Am I worrying too much?)... And even then, I don't know if collision detection would be possible (This is something that I cannot find on the 18F datasheet, hopefully someone here has a better understanding of it's capabilities). Any thoughts anyone?

This kind of thing is why I'm trying to make a IIC slave driver for the PIC, so in applications which require a little more cycles than one core can handle, a second core could be controlled by the first, and do all the hard work... Or a third core... etc etc... This is turning out to be rather difficult though, so although I'm sure I'll finish it, if it is possible, it might be a long time :(

oooh, perrrty :)

Nice work Thorsten. I spent most of the weekend toying with this :) Can't wait to see the example with the extra DIN SR used.... I'm not sure what you mean about the separate chain...But I'm sure I'll find out soon :) Very cool.... 8)

Sounds cool... LOL :D

mighty kind of ya D2k :)

Congratulations Artesia! /me throws streamers and sets off fireworks :D Big ups to all the peeps who made the effort to create a logo for the good of the whole community, you guys rock! Thanks!

/me calls out Duuuuuuuuuuugggllllllle!! You've got a PM mate ;D

;D ;D ;D 1024 buttons?!!??!;D ;D ;D Thorsten you never cease to impress me man! It seems like every time I have a problem with the design of my sequencer, a few weeks pass, and suddenly, you create the solution...

/me does a little dance Go Thorsten! Go Thorsten! ;)

Hey TK, As you might have read in my big post this morning, I've been working on some IIC code lately, so this is of interest to me... Would I be able to take a look too? Just curious... anything else new in 1.7? ;) Cheers

Hey all, I've been looking into the way I should go about designing an application which requires multiple cores, and I've realised that due to the inherent latencies of sending MIDI information, using the MBLink functions would just be too slow. As such I figured that the best way would be to use the IIC (I2C) bus. From what I can gather in the code, the IIC routines which exist will only allow the core to be a master, and they don't seem to be checking for collisions and so won't work in a multimaster environment. (I could be wrong about this!) So I have two jobs on my hands... The first is to write some new IIC routines to allow slave mode, and to collision check when in master mode, so that multiple masters on one bus will work. The second is to design some kind of MIDIBox Core Module Intercommunications Protocol that will be a language for the cores to speak, over the I2C buss. Obviously this is not a small job, but I'm pretty keen to do it, so I thought I'd drop a quick post and see if anyone (especially you Thorsten) has any ideas on this. Of course I could just go ahead and write the code up for my own good, but I think it would be best for the community here, if I do this in a way that will allow the code to be used for other applications. I guess what I'm saying is that I want this to be a protocol that can be used widely for many different customised MIDIBox apps, not just my own I'd really like lots of feedback on this, so if you have any thoughts at all please post them :) I went to work early today so that I could write this post :) Sorry it's so long! :-X

If using J5 as a DIN instead of an AIN, can the inputs be multiplexed like with a DIN module? This would allow up to 256 Digital Ins, but obviously no analog ins... I'd really like that!