jackchaos
Members-
Posts
104 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Everything posted by jackchaos
-
Because you have the hardware working and you have the development environment working. As long as you still have flash ROM available, you can make it do whatever you want! That's the fun part.
-
You're officially in the 'fun phase' of development.
-
I agree, Nice work Julien. Does the Arpeggiator work?
-
Looks like everything is coming along nicely. Congrats! P.S. You can attach files directly to your posts here, and later remove them if necessary.
-
Julien Is it working with 1 Matrix 1000? Is the edit buffer working too? I'm looking forward to seeing the product of all your hard work on YouTube. At least a demo of the controller and 4 Matrix 1000's.
-
Julien Congrats on getting this far! Are any of the controls working... pots, leds, encoders? Its been a while since I looked at the source but taking a quick look... Apologies, the DIN/DOUT config could have been made cleaner. Yes you will have to edit both din.c and din.h to config pins. din.c: Has to be filled in (DIN_ConfigMap[32]) The dins need to be listed in order that correspond to their pin number in the array. And of course each entry must point to the the DOUT pin for its corresponding LED. din.h has a few of the pins in din.c #defined to improve code readability wherever its used. So make sure anything in din.h that starts off with #define DIN_ or #define DOUT_ pots.c: Rearrange the entries in PotConfigMap[] to correspond to their pin positions. Then edit the #define POT_OSC1_***, POT_FILTER***, etc. in pots.h to match their config in pots.c
-
Modularman First, let me apologize for the late response. I've set it up so I am notified when new reply's are created. Second, thanks for your interests and I wish you the best making your Chaos Matrix. As for your questions, MIDI merge: I got lazy with the MIDI merge issue and ended up buying an old MIDIMan merge box on eBay. You could just as well build your own merger using one of the projects on this site however. The Chaos Matrix will work fine without one, but the buffer synchronization features will not work without the merge. 2 Matrix's: That's a good question. I do not have 2 Matrix's to test this with, maybe you can test for me. Try sending a couple of sysex messages to the first unit in the chain, and test whether you get the response from the MIDI out on the second unit. Request Edit Buffer, you should receive 275 bytes back F0 10 06 04 04 00 F7 Then send a parameter change, DCO1 Frequency high: F0 10 06 06 00 3C F7 low: F0 10 06 06 00 10 F7 If both synths change OSC1 pitch, then the Chaos Matrix will work editing both in a 2 unit mode (12 voice) without any changes to the firmware. As for layering two different sounds on top of one another, the Chaos Matrix currently doesn't support this without changes. Please, keep us up-to-date on your progress. Regards, Patrick
-
julienvoirin The software is pretty much complete. I've attached the most recent version to the original post. I realized you're not building a Chaos Matrix but the source will make a useful reference for your own project.
-
TK, I am sincerely honored. Part 2 Part 3
-
Optionally you can have the filter cutoff knob send CCs instead of sysex. The sysex is necessary for programming and saving a patch. However the cc improves performance if you want to tweak while playing. When you enable this feature in the filter menu, the first unused matrix modulation bus is used to modulate filter cutoff with lever 3 (breath controller). The filter knob will then send breath controller CCs instead of sysex.
-
Posted a video demonstrating the Chaos Matrix. Link also provided on the original post.
-
I sent you an email to the address on your website.
-
How so? I need two MIDI inputs. One for a keyboard controller or sequencer, the other is for the Matrix 1000 (this is how I get edit buffer sync to work). The midi out goes back to the Matrix 1000.
-
Updated the photo on the OP with its new wooden enclosure. I'm getting very close to completing this project. I still have a few things to do. The cabinet was built with oak boards from Lowes. I used the howto here as a reference: http://www.synthesizers.com/diycabinet.html What's left? The electronics need to be mounted inside the wooden enclosure. Rear panel with MIDI & power jacks A MIDI merge has to be built, its necessary for the edit buffer sync feature. The encoder setup isn't perfect, I still get occasional skipping. A few minor software adjustments
-
I was more inspired by this monster when it came to the panel design. http://www.vintagesynth.com/oberheim/new_oberheim_obx.jpg Download the FrontPanel Express file attached to the original post, you can see which controls I decided to dedicate to a pot or button. All the other controls are accessed through the soft panel (lower half). On my wiki, you can see a photo of the prototype... which had a LOT more dedicated controls. I later decided to simplify it.
-
Thanks again LyleHaze I understand, I may have mispoke about the filtering MIDI in the original post. I can easily filter now what coming in on the MIDI in jack right now. I gues all I need is a merge on one MIDI in. Considering my inherent lazyness, I'll go for the easiest solution possible. To buy a MIDI merger on the market would cost me as little as $60 USD new, maybe a lot cheaper used on eBay. A lot of them require no additional power supply to make them work. I've not decided yet. It still may be an option.
-
Not sure what you mean. My design is 24 inchest wide and wouldn't fit. The control surface electronics are made with a few small prototype boards to hold the buttons. The pots are mounted directly to the aluminum panel. Are you saying you have a PCB for a control surface? Post a picture, we love pics around here. :)
-
I would recommend getting a hold of this: http://wolzow.mindworks.ee/analog/m1k-midi-spec.htm it covers everything, including the firmware bugs and undocumented sysex opcodes. It also includes documentation on sending patch parameter changes. I've read that the Matrix 6 has a poor sysex implementation and is a bit broken, you might try looking it up before starting. I'm very close to completing the software for my project and will upload it svnmios.midibox.org. Below are the two main MIDI routines. void MIDI_SendVoiceParam(unsigned char param, unsigned char value) { MIOS_MIDI_BeginStream(); MIOS_MIDI_TxBufferPut(0xf0); // begin sysex header MIOS_MIDI_TxBufferPut(0x10); // mfg MIOS_MIDI_TxBufferPut(0x06); // device MIOS_MIDI_TxBufferPut(0x06); // voice parameter byte // transmit the parameter number MIOS_MIDI_TxBufferPut(param); //transmit the new value MIOS_MIDI_TxBufferPut(value); MIOS_MIDI_TxBufferPut(0xf7); MIOS_MIDI_EndStream(); } void MIDI_SendMatrixModParam(unsigned char mmbus, unsigned char mmsrc, unsigned char mmdest, unsigned char value) { MIOS_MIDI_BeginStream(); MIOS_MIDI_TxBufferPut(0xf0); // begin sysex header MIOS_MIDI_TxBufferPut(0x10); // mfg MIOS_MIDI_TxBufferPut(0x06); // device MIOS_MIDI_TxBufferPut(0x0b); // matrix mod parameter byte MIOS_MIDI_TxBufferPut(mmbus); MIOS_MIDI_TxBufferPut(mmsrc); MIOS_MIDI_TxBufferPut(value); // all matrix mod values are 7 bit signed MIOS_MIDI_TxBufferPut(mmdest); MIOS_MIDI_TxBufferPut(0xf7); MIOS_MIDI_EndStream(); } When you send a value, make sure its in proper range, because the M-1000 will go silent if its way off. I use potentiometers for most parameters except the matrix modulation bus, where I use an encoder. The potentiometers require a conversion from 10 to 7bit. Then you have to scale the value down and convert it if it needs to be an signed value. unsigned char getvalue(unsigned char pin) { unsigned char value; // scale 10bit to 7bit value between min and max boundary value = Scale_7bit(MIOS_AIN_Pin7bitGet(pin), PotConfigMap[pin].min, PotConfigMap[pin].max); // convert values for signed parameters switch (PotConfigMap[pin].valtype) { case SIGNED7: value = Convert_7bit_Signed(value); break; case SIGNED6: value = Convert_6bit_Signed(value); break; default : break; } return value; } //////////////////////////////////////////////////////////////////////////// // This is an assembly optimized function which scales a 7bit value between // a minimum and maximum value ///////////////////////////////////////////////////////////////////////////// unsigned char Scale_7bit(unsigned char value, unsigned char min, unsigned char max) { // scaled value is (<8-bit random> * ) >> 8 PRODL = value << 1; // 8bit value PRODH = max-min+1; // range __asm movf _PRODL, W mulwf _PRODH, 0 __endasm; return min + PRODH; } // converts a pots 7 bit pot value to a signed 7 bit with zero at center position unsigned char Convert_7bit_Signed(unsigned char value) { return (value + 0x40) & 0x7f; } // converts a pots 7 bit pot value to a signed 6 bit with zero at center position unsigned char Convert_6bit_Signed(unsigned char value) { return (value + 0x60) & 0x7f; }
-
LyleHaze I never paid any attention to the IIC MIDI Module. According to the docs, it looks like a good idea but will require additional software on my part in order to read from the 2nd midi input. Am I reading it wrong? However a MIDI merger wouldn't require any software changes and still give me two inputs which is exactly what I need. The second input would be used to connect the Oberheim out back to the Midibox so I can receive its sysex data... which is all that would ever be sent.
-
I'm looking for suggestions on how to implement a second MIDI input on my midibox. I've nearly completed all the software for my custom midibox. It is a remote programmer for a Oberheim Matrix 1000 synthesizer. It works by passing note on/off data from its MIDI IN, and adding sysex data to its MIDI out onto the Oberheim's MIDI in. One important feature is the ability to synchronize the edit buffer of the Oberheim to the edit buffer of the Midibox. When a program change is issued from the Midibox, it also requests the edit buffer of the oberheim. The edit buffer is sent from the Oberheim MIDI out and sent back to the Midibox where the data is displayed and handled. Currently, I have this working through my laptop with MIDI-OX using the PASS SYSEX feature to route the sysex data from the Oberheim back to the Midibox. Using my laptop is not ideal obviously. I need to implement this two-way communication using just a keyboard like so: [KEYBOARD]-->[MIDIBOX]-->[OBERHEIM] ^ | |____________| If I could add an additional MIDI input to my Midibox, it would resolve the cabling issues. But according to the docs I've read, it's not possible. I'm currently using 1 pic 18f4620 core, 1 ain, 1 din, 1 dout. It looks like a Midimerger with some MIDI filtering might do the trick. If so, I'd like to build it inside by current project, using the same power source. If not, I guess I could build an outboard Midimerger. Can anyone suggest a way I can get the Midibox communicating both ways with the Oberheim and still have a keyboard connected?
-
warnings when compiling my app for 18f4620
jackchaos replied to WickedBlade's topic in MIOS programming (C)
I receive these warnings too after changing the processor to 18f4620 and have not been able to resolve them. warning: processor mismatch in "gptrput1.o" warning: processor mismatch in "mulint.o" warning: processor mismatch in "gptrget1.o" My app works fine however with no noticeable issues so far. Originally I was compiling for a 18f452 and later changed to a 18f4620. The makefile for my project is now set to "PROCESSOR = 18f4620" obviously. I've tried recompiling the sdcc lib after updating the processor in the make file here: D:\SourceCode\MatrixBox\Mios_Base\lib\libsdcc\sdcc_2.8.0\ but I get this error: make: *** No rule to make target `_output/fixed16x16/fps16x162schar__mios-gpasm-tmp.s', needed by `libsdcc.lib'. Stop. Here is a copy of my path variable PATH=C:\MSYS\1.0\bin;C:\Program Files\gputils\bin;C:\Program Files\SDCC\bin;C:\MinGW\bin;C:\Program Files\SDCC\bin;C:\Pr ogram Files\gputils\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program Files\Microsoft SQL Server\80 \Tools\Binn\;C:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\Microsoft SQL Server\90\DTS\Binn\;C:\ Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\;C:\Program Files\Microsoft Visual Studio 8\Common7 \IDE\PrivateAssemblies\;C:\Program Files\TortoiseSVN\bin;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\SD CC\bin;C:\Program Files\gputils\bin and my MIOS env vars MIOS_BIN_PATH=D:\SourceCode\MatrixBox\Mios_Base\bin MIOS_PATH=D:\SourceCode\MatrixBox\Mios_Base -
Mios C sysex forwarding example doesn't compile anymore
jackchaos replied to sneakthief's topic in Testing/Troubleshooting
It should read: static unsigned char fx_status; -
LyleHaze, Re-burning it was the only way to fix it... Thanks for your assistance. Regards,
-
nILS, this is perfect and will work for me. We knew you were good for something! :) Thanks.