stryd_one

Yeh, please share the answer with everyone, so that others can benefit from your experience :)

Bluest shade of white I ever saw :D

Sweet as. Just my kinda layout too: simple, militaristic, easy.

I think the button you're searching for, is the one labelled "modify"...

Hah I hope that's a joke! Have you done the midi troubleshooting guides? How'd you upload the app if it doesn't receive midi from the PC? I hope it's OK, I changed the topic, because yours made it sound like a problem with the sequencer in the app... Can you describe the situation a little better? Some of it was confusing, like this:

;D

;)

Nice clean design. The VFD just 'makes it'. It is a VFD right?

74F786 Perfect.

Hi Frank, that's similar to the appnotes I posted above (wonder why yours wasn't in the search I ran?). It's actually more appropriate as it's for ECAN not CAN, so thankyou! As with those other appnotes, that's a different thing to MBNet though, so it would only really be useful for learning what the registers do.

Yeh? how many did you find? these things are pretty rare, I've not seen one in action since...well, since they were new. So, I assume seeing as you've studied it so much, that you disabled some of the operators until you found out exactly how to reproduce only the phase-shifted waveform? Do you have wavs? Patch files?

I moved this to misc, because this is an ableton usage question rather than a midibox troubleshooting one... The button is meant to send a note message, so the midibox is working :)

Yay!! See, there's method in my madness ;)

app_defines.h is the go, you could put it at the bottom: CSMD_POTBASE EQU 0x299 ;;holds POT# of top left pot in zone ;; ========================================================================== NOTE_SHIFT EQU 0x300 ;;holds value for note number shift This looks to be free also, and might be a better place: ;; used by drums.inc DRUMS_STATE_BEGIN EQU 0x068 ; for 8 drum triggers DRUMS_STATE_END EQU 0x06f DRUMS_MAX_VALUE_BEGIN EQU 0x060 ; for 8 drum triggers DRUMS_MAX_VALUE_END EQU 0x067 DRUMS_CTR EQU 0x068 ; used as loop counter ;; used by Bassman's note shifting code NOTE_SHIFT EQU 0x069 ;;holds value for note number shift ;; ==========================================================================

polarity is important, yes. diodes are a one-way street... I see what you mean now... You'll need to make (fairly minor) modifications to the matrix scannig functions, to use QBAS's code.

Don't you want it to work for note off's? ;) Define a new variable for this, and set it's value as 0x0c in a meta event like you said, then around line 56 of midi_evnt.inc: ;; sending three bytes: MIDI_EVNT_Send_8x ; Note Off MIDI_EVNT_Send_9x ; Note On ;; Add your variable to evnt1 here MIDI_EVNT_Send_Ax ; Aftertouch MIDI_EVNT_Send_Bx ; Controller movff MIDI_EVNT0, WREG call MIOS_MIDI_TxBufferPut movff MIDI_EVNT1, WREG andlw 0x7f call MIOS_MIDI_TxBufferPut movff MIDI_EVNT_VALUE, WREG andlw 0x7f call MIOS_MIDI_TxBufferPut rgoto MIDI_EVNT_Send_End

That's exactly right... in fact I think (nearly?) all the midibox apps work like that. I agree, it's extremely unlikely to actually collide, but you know electronics... always screwing up when you least expect it ;) Also, we don't just write one byte at a time... if we're updating the LCD it's going to be a byte (one of these cycles of error checking included) for every character... our LCD driver is quickly becoming slowed down by all these checks... We could maybe reduce the slowdown by, instead of handling the arbitration with every write cycle, we could swap access between each core periodically, say, at the beginning of the LCD update functions... but of course that is going to mean we can't make use of the LCD enable lines, so you'll need at least (one or) two spare pins. Yer maybe ... (It's fun discussing it though :) "text adventure...") But.. maybe not ... As above, in order to speed this up, we can separate the arbitration process from the actual LCD write, using two other pins. This would have the added benefit of enabling the apps to share control, not only of the LCD enable lines, but of well, any peripheral they are attached to, FM included But, even as a theoretical discussion, this is fairly extreme. Essentially, we're talking about Asymmetric Multi-Processing, and although it's possible, I can hear a wise little voice from my memory saying "why not use a 32bit micro instead, if you want to do that?" ;D Regardless, I am curious about this (I'm johnny 5: "inpuuuut!"), so I've done a bit of research into defeating buss contention, and I think I can safely say that there's no universally accepted "right" way to go about it. In fact, I have collected up links to about a dozen patents to different methods, and a handful of different designs as well, and that's just the stuff that's freely available. I had a lot of trouble sifting through the noise (we don't really want to know too much about PCI buss contention in dualcore pentiums, or timing-based buss contention with a single processor) so I'm sure there would be hundreds of ways to do it that have been published... I've seen everything from dedicated MCU's to elaborate logic to CPLDs to using a single pin with automatic latching circuitry... I ran the question by a friend who used to do military encryption hardware and he went the logic route, we had a rather interesting whiteboard session :) So anyway, I don't know if we're actually going anywhere here, but it's an interesting learning experience!

Props Nilly

It's probably the patch you're using, is my guess... If it's intentional and part of the design, then it'll be for psychoacoustic effect, and maybe it doesn't sound so good because your setup isn't quite right? Edit: LOL!!

Yeh quasimidi stuff is underrated. Rare though... Don't worry about the operation, the cutting doctors are far more advanced than the chemical doctors. You should worry more about a headache tablet ;) Glad the gig was rockin. Feel better soon!

;D

Nice document!

As tilt and I have discussed: [tt]FM Core checks RAO ;(which is connected to SIDcore RD7 - E pin) RA0 returns high ;(meaning SIDcore is writing to LCD) FMcore returns without writing, does whatever else it does... RA0 returns low ;(meaning LCD bus is free) FMcore sets RD7 high at the same time SID sets RD7 high FMcore writes to LCDat the same time SID writes to LCD [/tt] Race condition still exists ..... dammit how to get around this?

Nice one :)

Search wiki for button DIN SR Pin, and youll see: http://www.midibox.org/dokuwiki/changing_din_pins?s=button+number That's talking about changing the SID source, but the beginning is still valid, and include formula for converting the button number to SR:Pin pairs. I'll make it real easy on you... grab a copy of Calcutta, an excellent (although java based) calculator http://home.arcor.de/0xdeadbeef/calcutta.jnlp (you can download a .jar file for a local install from here http://home.arcor.de/0xdeadbeef/Calcutta.htm ) Paste this line: function get(evt) { sr = floor( ((evt-1) / 8)) + 1; pin = (evt-1)%8; out = "SR: "+(string)(sr)+ ", Pin: " +(string)(pin)} Now to get your results just type get( whatever your event number is ) It'll look like this (only in colour) function get(evt) { sr = floor( ((evt-1) / 8)) + 1; pin = (evt-1)%8; out = "SR: "+(string)(sr)+ ", Pin: " +(string)(pin)} out = <UNDEF VALUE> get(8) out = "SR: 1, Pin: 7" get(56) out = "SR: 7, Pin: 7" get(58) out = "SR: 8, Pin: 1" Enjoy! PS that calculator app is rad.