stryd_one

What? You don't have to stream the on/off to the sid, you just send the pic a sysex command and it does the rest :) Course.. PIC's don't pack a lot of sample ram. ;) Sure you could look at SRAM but... uhm... speakjet?

The bits that do that aren't the most accurate things in the world... probably good for a lofi approach, but won't be pretty ;)

Maybe... Note that the stock availability is in the future... It's been that way every time I've checked it (regularly for years). Fancy emailing AD?

Yeh, and making your own buffers should be a snap. Although, if you want to use the 75019 with many-to-one, you still have to make sure it doesn't get overdriven somehow. I dunno how, hence needing someone else to do the layout :) ... And there's still the problem of availability. Although, I'd expect we could dig a few up... a bunch on ebay is good enough for us to get started (I'll buy the other 9 if it's workable) but it's not my aim to make it just for me.

That's essentially the same as the 8113, but lacks the buffers (opamps). Alas, it's been discontinued and replaced by the 8113, so it's not suitable as it will be harder and harder to find in future. Edit: http://stromeko.synth.net/DIY.html#Matrix32x32

Problem with surplus is that you end up with a design noone else can build. No good. You could DIY the relays, but chances are the mass produced chip sold especially for the purpose will sound better, so that would defeat the purpose.

Yes I think we both learned a lesson here.... First, bugfight and I helped ultra for some time, only to find that the encoder table was filled incorrectly. Solution? Use the examples. Also, I didn't try it myself because I didn't have a DIN board soldered up. In the end, I spent more time typing, trying to help, than it would take to solder up the board. Solution? Just solder it and try it. It may take longer, but at least you get a soldered PCB a the end ;) So, my apologies TK. Your effort wasn't a waste and we do appreciate it, and usually make use of it... just... sometimes we do daft things. Lesson learned!

The problem with relay based matrices is that they are huge, and expensive. TK: :o What's THAT?! :D

did you even read our posts? ;D TK posted a link and then i told you to read it. Read it!

Yeh, that's why I keep asking these guys how their host expects it to be sent ... and why I say that it shouldn't be referred to with one universal name like "relative midi", and expect that to be the only specification given ;) Now that I see this again after seeing TK's code... Go read TK's post at the other thread, see his example... is this what you mean? If so, don't forget the "& 0x7f", or you may accidentally send a status byte if your incrementer is extremely high (shouldn't happen, but....)

Yeh I know all that...Remember I was in the chat and helped you fix that bug? ;D But read the midi spec and you won't find "relative midi". The only such thing is an RPN. The way your gear is working (sends a signed 7bit value) is a sensible implementation, and it is becoming the most widely used.... but similar - but not the same - methods have been used in the past, so it should not be spoken of as a universal implementation, because different devices and hosts do it different ways. Edit: like NI apparently, and I do the same as them in my seq ;) Exactly. Ever wonder why that is? ;D Because there's no such thing as relative midi CC's so everyone cooks it up a different way. You can bet your bottom dollar that it'll be included in the midi spec one day because it makes sense with modern gear ... But it's not yet :) Regardless, this is great info for people trying to get it working. I'll try and give up something useful: unsigned char s_to_rel(signed char input) { //input a signed char unsigned char sign; //holds the sign for later unsigned char output; //temp var for the output sign = 0; if (input&0x80) sign = 0x40; //set the 7th bit sign for later output = ((unsigned char) input)&0x7f; //typecast then mask out the sign so we can work on the value if (output&0x40) output = output>>1; //if it's using the full range, shift right for midi compatibility return (output|sign); //put the sign back on there and return unsigned char representing signed 7bit } signed char rel_to_s(unsigned char input, unsigned char res) { //input unigned char and range unsigned char sign; //holds the sign for later signed char output; //temp var for the output sign = 0; if (input&0x40) sign = 0x80; //set the sign for later output = ((signed char) input)&0x3f; //typecast then mask out the sign so we can work on the value if (res) output = output<<1; //if res is !0 then make this use full 7bit res+sign return (output|sign); //put the sign back on there and return it } @tk hahahah we thought acceleration was built in but couldn't find any documentation and didn't have luck making it work, so thought it must have been part of the mb64 app... d'oh!

No sweat ploggy, I have been working on a few things while you were away. Work hard on your exams and good luck!! We'll see you soon :)

As per my wiki page "I will work on a digitally controlled analog switch matrix." I've been talking this up for some years now, with you too, DrB, I guess you forgot :) there's a 5 year old thread that didn't eventuate, and I am still waiting for someone to make the layout. Someone has already volunteered and it is on our list of projects to do. The chip to use is the AD8113. You can switch one-to-many with the chip, if you want to do many-to-one then you need a mixer not a switch array ;) You could always put a passive mixer after some of the outputs. The trick is, that to get decent quality, you need to make it at least 2 layer PCB, up to 4. There are notes about this in the datasheet. In addition I have insisted that it be made in a way that will make it useful for many different people, not just one person - that means thinking about connections to chained boards for different architectures (16x32, 32x32, etc) and separate interface boards (balanced, unbalanced, etc), compatibility with existing apps, different CS boards and such. For a prime example of the right way to do it, see the mb-mixer board recently posted. If you're interested in helping with this project (*cough*layout*cough*) please let me know ;D

They could if they wanted to. But that wouldn't help sell controllers :) Oh, so the axiom has a mode where you tell it that the knob should send knob movements as increments rather than an absolute value? That's not normal - as I keep saying, there's no such thing as relative midi - I'm guessing that the axiom has implemented a proprietary workaround which is common (sending signed 7bit values of inc/decrements) because a modern DAW has (finally caught on and) implemented it. Sometimes it is handy... But I find that fast/slow mode is more functional as it allows more control. 67? you mean -3? :D Should be more intuitive to use a signed value and then typecast it before you call txbufferput.

Well if you want to support acceleration in hardware (Does Live not support this itself?), you need to use a timer/counter to calculate how many encoder inc/decrements in a given period of time, and then use that number to control an inc/decrease in the amount of the change you send to the host.

I'm not great with hardware so I'm going to let someone clever answer that question in case I get it wrong and blow the thing up :) ...but I had to say: Now THAT's a pirate! Yarrgh!

More likely you're the only one game to try it yet :)

Maybe Live supports 16 or 14 bits for the virtual knob values, so absolute mode will be scaled from 0...16384 or 0...32768 to 0...127 to match midi, and the relative mode allows for finer control at the higher bit depth? You could test this by sending it a hardcoded incrementer value of +63 and see how far the knob moves around the dial . Just stick it in your init function and turn it on :) Edit: If it has the higher bit depth then you can just bitshift the controller value with a shift button or push button encoder to make it go fast as absolute mode (or fine if you prefer). It'll send the full throw of +/-63 every time you move one notch. Actually, that's another way you could test it ;)

Unfortunately some people are not very nice and are happy to steal from a charity. @Everyone: Yep, I know.... We all feel the same way. Let's leave it behind and keep working on our kits :) Edit: removed the swear words. Now back to my code. Fun! :D

Notepad is no good, it's linefeeds clash with gpasm.... But you can use wordpad. Or notepad++ like a sane person ;)

This topic has been moved to Testing/Troubleshooting. [iurl]http://www.midibox.org/forum/index.php?topic=11197.0[/iurl]

That means your search path was not complete.

Please do man :) My C64's need new life breathed into them...

You say relative CC like it means something universally, but it doesn't - MIDI CC messages are absolute. Always. However - If your host utilises the absolute values as an offset, then it has the effect of relative mode.... but every host can implement that differently.

Don't crosspost please.