alanjcastonguay

Back to one of the first questions for clarification; Those 64 ains, 128dins, 128douts are the limitations on (the handling of) the physical number of pins, right? Is there a higher limit to the number of virtual banked pots as well, or does the internal virtual controller max out at 64/128/128, with that example being intended for a full 1:1 mapping of physical to virtual pots/buttons?

First thing I did after registering this account was to send Duggle a PM. I havn't heard anything back, nor can I find evidence on the forum that a finished solution was published. Thorsten, are those PIC16F88's just forwarding all data they recieve down the line, with J3 being the I2C interconnect?

Thanks for the clarification, Thorsten. Thanks for the welcome. 2) I plan to utilize an Alps touchpad 808-874649-002-A as an X/Y controller. It outputs trackpad data in accordance with the PS/2 protocol. Rather than burden MIOS with interpreting the PS/2 data, I was going to write a handler into another dedicated microcontroller. Specifically, an Atmel AVR microcontroller (chosen because I have experience writing assembly for it). This microcontroller will buffer the incoming PS/2 data, decode the absolute X and Y coordinates, and make available on its outputs two 7-bit numbers corresponding to the X and Y coordinates last touched. I think that the inbound data should map to a pair of virtual pots. The data on those 7x2 lines is not going to change at a faster rate than someone can swing their fingers over the X/Y pad, and missed information (aka, PIC reads value d[0] on first pass, data available is updated to d[1] between passes, and PIC reads value d[3] on second pass) is of no concern, as there wouldn't be enough time to push that data over midi anyway. It would be a concern were the pad to be put in relative mode, and expected to link to a relatively-positioned vpot. As it is, I think it makes more sense to just override any associated value already assigned to the vpot. The only issue I'm struggling with is how to avoid the (rare, but bad) situation where one device is updating the state and the other reading, resulting in mismatched chunks of data, and thus wildly swinging data errors. Updating the output registers in a synchronous fashion would solve this. To that end, I propose flipping the data over to the AVR's output registers when RC on J1 on the DIN goes active, using an hardware interrupt in the AVR. At present, I am not sure how much latency this would add. I suppose I could instead replace the last two 74HC165's with a direct connection to the AVR chip, and shift out the last 2 bytes of DIN-age myself, but this would require the other microcontroller to keep pace. However, as I don't really care about the cost of extra 74HC165 shift registers (cheap as dirt), and the smallest AVR chips I have on-hand are going to have at least 16 free output pins, there's no significant advantage to providing a direct serial shift interface to the data other than pretty-ness. I think that using another processor to pre-cook the input ps/2 data makes sense, and providing the data in a form that the PIC18F can sample whenever it feels like doing so significantly simplifies implementation. edit: The midi implementation detail in that older manual is simply perfect. Gracias.

I am in the planning stages for my own mios-based controller for Ableton Live. There are several points which I am slightly unsure of, and the available documentation doesn't appear to clearly answer these in a definite manner. 1. Would I be correct in assuming that MIOS and PIC18F452 support all of 128 digital inputs, 128 digital outputs, and 64 analog inputs at the same time? It appears that the pre-mios PIC16F877 applications such as MidiBox64 and MidiBox64E had various restrictions on the number and type of inputs, and the MIOS-based re-implementations of these applications (64 and 64E) carried those restrictions forward (like MB64E not supporting AIN), even though the underlying hardware and OS no longer carry those restrictions. It appears this was done to maintain pin-computability between an old PIC16F programmed with 64E firmware and a new PIC18F with the new 64E firmware. Thus, one can create a new MIOS-based application using either C or asm without those artificial restrictions, and make full use of the features provided by MIOS and the PIC18F. Am I correct in my understanding? Is an example of such an application? 2. Digital inputs appear primed to handle single momentary-contact pushbutton switches, or pairs in rotary encoders or data wheels, which are tied internally to virtual pots. Analog inputs are geared to handle pots with absolute values 0-127. Is it possible to group more than 2 (probably consecutive) digital inputs to input some larger absolute value to a Virtual Pot? As in, instead of using a DAC <-> ADC combination to glue two pieces of purely digital equipment (with common vcc and gnd) together just to get a 0-127 value between them, I would prefer to provide output from digital_source on an 7-wire bus conveying a binary-encoded number 0-127 which is accepted directly by a DIN, and interpreted as above by MIOS. What provision for such inputing data with such an encoding over DIN is provided? 3. Is a complete list of the standard Logic/Mackie Control mappings available somewhere? 4. Are jog wheels (or datawheels) usually implemented the same as other rotary encoders (2 DIN lines, one pulsed for increment, one pulsed for decrement)? Please post a url to required reading or liberally correct any mis-assumptions I am making.