jackchaos

Never mind, I found this document. http://www.midibox.org/dokuwiki/doku.php?id=stryd_one_codeblocks Which introduces me to Code:Blocks and I believe the included LIB is what's helping me. You guys are great.

Is it possible to cast from Char to Int? Like: unsigned char a = 5; unsigned int b = 1000; int c = b * (int)a; When I try to do such a thing I get the following error when running make: Compiling main.c Processor: 18F452 ================================================ Linking project error: missing definition for symbol "__mulint" ERROR!

Why is that?? Are they the same length sysex string? You have to imagine the Matrix being a digital modular synth where you have the option to route 1 of 20 modulation sources like, levers, pedals, velocity, pressure and LFOs, ENVs, portamento etc. To one of 32 desinations like, DCO1 Frequency, VCF Freq, DCO2 Pulse Width etc. From what I understand, the Matrix cpu has to do some acrobatics to make this work, to completely change the signal path like this. Oberheim didn't design the Matrix 1000 for real-time editing of all parameters... though some respond nicely for example: DCO1 to DCO2 Mix level requires no slow down in MIDI transmission at all. VCF Resonance works great too. But DCO1 to LFO1 chokes when I move the pot from one extreme to the other quickly. The customizable matrix modulations all respond slowly to pot events.

I did this: MIOS_MIDI_BeginStream(); MIOS_MIDI_TxBufferPut(matrix sysex byte); MIOS_MIDI_TxBufferPut(matrix sysex byte); MIOS_MIDI_TxBufferPut(matrix sysex byte); ... MIOS_MIDI_TxBufferPut(0xfe); // active sensing ...3 to 6 times MIOS_MIDI_EndStream(); I tried sending 0xfe both before and after the MIOS_MIDI_EndStream() and was unable to hear the difference while moving a pot. I do not think this was having any affect on how the Matrix was handling the flood of SYSEX being received when moving a pot rapidly. BTW: Whats the difference between using MIOS_MIDI_BeginStream() and MIOS_MIDI_EndStream() and not using them at all when sending MIDI. I notice in the sample code and applications, Begin and End Stream isn't always used. I started working on a solution this morning right before I had to leave for work. Its not elegant but I think it will work. I'm anxious to get back home and finish it. I have a lookup table that holds configuration info on each pot like param number, min/max value, if the value should be handled as SIGNED or UNSIGNED etc. I want to add another config parameter that describes its transmission frequency (skipping values); some pots are fine, others need to be slowed down a little, some need to be slowed down a lot. For the pots that need to be slowed a lot, once its moved, I'll skip x (say 4) values but keep track of the last value. When I stop moving the pot, MIOS_Tick is notified a special pot value (last value) needs transmitting and sends the value there. So, in essence. I'm reducing the resolution but my last displayed value, after I stop moving the pot gets transmitted.

The problem is, I don't understand TK's solution. I sent that byte over MIDI right after each SYSEX message and midiox showed it as "Active Sensing". I don't understand how this is supposed to work. Can you explain what he meant? The MIDI cabling is fine. Sending standard note on/off data and controller CC data works fine. But, sending a burst of SYSEX data to alter some parameters for a voice like DCO1 Freq to LFO2 modulation while tapping notes on the keyboard produces a noticable stutter and sometime a hung note for a couple of seconds.... especially if you move the pot quickly from min to max. The flood of SYSEX for some parameters is too much for the MATRIX to adjust and alter the sound... The Matrix 1000 was not designed for real-time sound editing... it was designed to have a PC and a sound editor upload the patch parameters slowly.

Allright. Although skipping every 6 AIN notifications keeps the Matrix from choking, this isn't a good solution. Changing a value from to the next value is difficult because I've in essence reduced my resolution. I think the right way would be to only send the SYSEX value when the pot has stopped moving. The only way I think this is possible is to either count a timer or count cycles some other way and keep track of that last pot that was in motion and what its last value was, ignoring all the other values. I'll work on this but if anyone can save me time and point me to an obvious feature that might be in MIOS, let me know. Again, thanks!

Stryd, Not sure what you're asking. Can you elaborate? TK I resolved my issue above by doing the following: void AIN_NotifyChange(unsigned char pin, unsigned int pin_value) __wparam { if(PotUpdateCount == POT_UPDATE_INTERVAL) { // send sysex PotUpdateCount = 0; } PotUpdateCount++; } With POT_UPDATE_INTERVAL of 6. I only send SYSEX, for every 6 AIN notifications. So far, this works great and I can't really tell things have slowed down. The Matrix stuttering is marginal now, at least. Thanks

I'm building a knobby programmer for my Oberheim Matrix 1000 analog synth module. All the pots are sending SYSEX data to the synth and most of the parameters do not like receiving the flood of SYSEX MIDI at the rate it's being transmitted. I had the same problem last year with a commercial MIDI controller but was able to resolve it by adjusting the update interval config option for the rotary encoders on a Behringer BCR 2000 which worked perfectly on the Matrix. Is there a way I can do the same in MIOS? I'm running 1.9 MIOS and an edited version of this C application: ain64_din128_dout128_v2_0.zip Thanks.

I thought I would post some images of my progress like everyone else. To recap: I'm building a control surface to an Oberheim Matrix 1000 analog synthesizer. the M1000 was build in the late 80's with complete MIDI/SYSEX control over all it's sound parameters. The synth is incredibly programmable and expressive except for the fact you can only do it with a computer. My early estimate counted over 70 knobs and 100 buttons & LEDs would be required. My goal is to have an intuitive surface to program the synth on the lines of an Elka Synthex panel: And an earlier Oberheim Synthesizer: Here is a pic of my Matrix 1000 - the subject of my project. I also purchased a Behringer BCR 2000. I've been using this to test how the M1000 responds to realtime SYSEX on the patch parameters. The software that came with the BCR wasn't sufficient for the Matrix - it was designed more for virtual synth plugins and software MIDI recording, but I was able to hack the presets using a HEX editor and pretty much got it to do exactly what I want. The labelling on all the knobs account for nearly all the editing parameters available on the Matrix. A also drew up a mock panel in paint shop pro to see if I could fit everything I needed in a 19x10 rackmount panel. I found out I couldn't. My finished version will have to be a tabletop formfactor. The 1st thing I did was order a few parts from SmashTV. Soldering all the bits together was really fun. Before I bought a bunch of knobs and switches, I wanted to first make sure I was actually capable of taking on something like this. So, what I did was create a small prototype that would allow me to see how all the electronics connected together and learn a little about MIOS/MB64 assembly. I used an inexpensive plastic container to house the electronics and front panel because it was so cheap and easy to cut holes for the various parts. Later I was able to change MB64 code enough to have each of my knobs and switches send the type of SYSEX messages I would need for my project to work. Once I was able to print my own messages on the LCD panel, I knew I could then proceed to the next step. The next step was to build a prototype containing all the surface controls and test out how I wanted to organize them for each of the synth parameters. There are over 99 individual parameters. I've begun creating a number of panels boards using the large panel board available from SmashTV. I have a large plastic storage bin that I'm going to use as a front panel for this protoype. I've actually have some components cut for it and mounted but I havn't got a photo of it right now.

I've purchased a number of these 'Strip Boards' from SmashTV and I'm fishing for ideas on how to use them. http://www.avishowtech.com/mbhp/images/Sstripboard.jpg and http://www.avishowtech.com/mbhp/images/LstripboardS.jpg I plan to mount my illuminated switch buttons on them and possibly use it as a connection point for pots and dins. If you look closely at the photo, you'll see the copper extends around the holes and across the board. Obviously this wouldn't work if I want to use holes that are on the same horizontal line. How would anyone recommend to isolate a soldered pin hole from another on the same horizontal row?

Kris This is a very common problem. The answer however is 99% always the same - Check, double check, triple check your soldering. Get a multimeter and set it for continuity and make sure every possible connection is true beyond every solder. Print out the wiring diagrams for the AIN and the CORE and check, double, triple check you have everything right. Read the documentation on the AIN: http://www.ucapps.de/mbhp_ain.html and make sure you've got everything covered. Trust me, it's always your wiring or the soldering.

Dave: I was following this description of btfss: "btfss: tests a bit in a file register and skips the next instruction if the result is set" I'm thinking 'set' = 00000001 not 'set' = 00000000 if bit is set (00000001), then do next instruction whic is clear. Looks like I've got the SET thing backwards. ...anyway, BTG is what I needed.

I just want to toggle a bits state. How do I flip a bit? [this isnt working for me] btfss CHAOS_DCO1_WAVE, 0 bcf CHAOS_DCO1_WAVE, 0 bsf CHAOS_DCO1_WAVE, 0 [uPDATED] I discovered btg by accident on the net. This is the first time I've come across it. Of all the PIC assembly links on the net I've gone through, I've never found this. btg filereg,0 does exactly what I want!

Is it possible to write new functionality in C on top of an existing application (MB64) with the assembly source? I'm interested in writing the logic to handle button and LED behaviors in C on top of MB64's assembly source. Thanks again.

I need to create a new pot behavior and I was hoping I could get direction on where to start. Some of the parameters I need to send with pots have to transmit sysex strings based on the following: A center detent value would transmit 0x00 (zero) ascii illustration ( | ) move it to the right and it increments to a max value of 0x3f (63) or (+63 7bit signed) ascii illustration ( \ ) move it to the left of the center detent it would decrement from 0x7f (127) (-1 7bit signed) down to the min value of 0x41 (64)(-63 7bit signed) ascii illustration ( / ) My synthesizer for the most part, recieves parameter values 0x00 to 0x3f, which is perfect. But for 28 of them I, it expects a signed value for -63 to +63. Any advise would be greatly appreciated.

I've created some custom meta handles in mb64_meta.inc. I know that you can assign a pot or button to one of the meta events, but where do I do that in the source files. I want my pot behavior to be hard coded without needing to change its behavior in the LCD user interface. MB64 has my pot assigned to a CC by default, where do I change this in the source files? Thank you! [ UPDATED ] A later was able to understand the source in mb64_presets.inc

I've made the necessary changes to mb64_meta.inc to transmit a sysex string containing values I need according to the inline comments. Where in the source do I apply a MB64_META_Handler_Pot event to a pot that already has a default behavior? I can change the behavior by using the LCD interface but I want to be able to set meta handler to the pot in the source. Thanks again. [ A FEW HOURS LATER ] After discovering the mk_syx.zip package and seeing how the the pots were set to their default behaviors, I was able to solve my problem. I was looking at the solution the whole time in mb64_presets.inc, but the comments in the file didn't help. POT_ENTRY 0xf0, 0x00, 0x00, 0x3f The first hex value '0xf0', sets a meta handler event to the first pot entry. The second hex value '0x00', is a hex value for the metahandler. 0x00 is for the first one, 0x01 is for the second... The next two hex values and min and max values for the pot as the comments in the file suggest.

I've got my prototype system set up for my Oberheim Matrix 1000 programmer and I've begun making the necessary modifications to MB64. I need a pot to transmit a range of values (0-63). I was able to do so by editing the last value on this line: POT_ENTRY 0xb0, 0x5b, 0x00, 0x3f in mb64_presets.inc What I see on the screen however, is the bargraph only going halfway up. I've been unable to see where I can change the scale of the bargraph for the pots, individually. Where in the source can I change the scale of the bargraph?

Screaming " most of todays multimeters have a diode test function (beep) if you're not shure." Bingo! Newbie learns something! I never cared to investigate the feature. Thanks Screaming Rabbit.

The interior of my LEDs look exactly like this image, except the length of the pins is reversed. My long lead runs into the triangle shap inside the LED. My short lead runs into the straight and narrow shape inside the LED. Here is the image from Smash's site. These are the LEDs I bought. So, before I solder anything else and potentially burn up more LEDs, can someone please tell me which wire (according to Smash's image of the LED, should I connect to VS ground and which wire connects to the DOUT pins? Thanks

I'm so confused on this... it ain't funny. The problem is, the diagrams on this site, isn't including what wire from a LED is what. I have a boat-load of LEDs that have short and long pins... I'm also fixated on the shape inside the red diffuser; on top of all that... my DOUT isn't making anything blink reliably. So, should I ignore the shape inside the red area and just concentrate on the pin lengths? Short pin (cathode) goes to VS ground; long pin (anode) goes to the DOUT pin. Oy freekin' Vey!

I found this image and I used it as a reference because I couldn't find this info here. http://web.mit.edu/~awozniak/Public/6.121/LED.html The image shows the short lead as being the cathode lead. And by looking at the LED closely, you can see the crescent shape. On the LEDs I got from Smash, the short lead isn't on the crescent side. It's just the reverse. So, now I'm confused. I've probably blown those 8 LEDs. When I wire them up, I went solely by the length of the lead to determine which one would be connect to a DOUT pin and which was ground. http://www.ucapps.de/mbhp/mbhp_doutx4_32leds.pdf The DOUT schematic shows the ANODE lead connects to the DOUT pins. The external image suggests the anode would be on the long lead. I'm guessing that image is wrong, right? The long lead should be the cathode, and the cathode lead should be connected to VS ground. Oy vey!

Smash I got 100 LEDs from you and I've been using them on my prototype setup. I'm a newbie when it comes to electronics but I've not read anything otherwise about LEDs. My LEDs light up once or twice and that's about it. When I initially got the package, I hooked on of them to a 5V source and it lit up a couple times then stopped. I figured I might have blown it for wiring it directly like that. Now I have 8 hooked up to my DOUT and by using the Debug Fuction features in MIOS Studio, I got the lights to light up 2 times and no more. Is there something obvious I need to be aware of?

Yes. I went back and went through them after posting this. Only 3 or so files were in unix format, the rest were fine. It looks like TK might have gone in and made a few last minute changes in a different editor with different newline settings. Back to work! Thanks!

I was able to get pass "error[129] END". The problem has to do with UNIX and WINDOWS carridge return differences. I use notepad++ which has a "CONVERT TO WINDOWS" feature. Now that I got pass the "error[129] END", the asm compiles with a messload of warnings. Is this normal? My main.ERR file has 2700 lines of errors..