/tilted/

I really need to watch my phrasing... Yes the big knob is analog. I probably should have written: Analog control is the better way, although I haven't tried the "big knob". take care.

A little, perhaps. It is probably a fair bet that any modern DAW program has enough calculation headroom to avoid clipping the internal mix buss in the digital realm. Here I agree. By "enough calculation headroom", I mean that a signal which reaches your "master fader" at higher than 0dBFS can be reduced by the fader without clipping to below 0dBFS. This is ok, but a bad habit to get into, as this does not work the same in the analogue world. My main point is that if you are doing you mix "in the box" and have no external monitor control system, but you do have a lovely shiny "master fader", it could be all too tempting to try to use your master fader as a monitor volume control. Assuming that your DAW is feeding audio at absolutely optimised level (ie the highest level your DAW puts out to your soundcard is 0dBFS, then you should let it do so. If you turn down your master fader to keep the neighbours happy, you will also be reducing your soundcard bit depth, because the master fader in a DAW is calculated before the DA conversion takes place. So assuming your gain structure is all good before the master (ie not clipping), and you turn down to say, -18dBFS at your master fader, you are basically chopping off 3 bits worth of data. For every extra bit in your digital audio "word", you double the voltage resolution you can represent. (ie you get an extra 6dB). At this point in the discussion, we usually get into matters relating to dithering and truncation, noise shaping etc. but we digress... A 9th pot should still be possible...

I agree. Not the big knob specifically, but external analog control is better. From an engineering perspective, you are much better setting your channel levels lower to avoid clipping, rather than overloading your master buss, then turning the master down. If you turn down your master level below 0dBFS, you are essentially eating into your bit audio depth. Surely no-one wants that??!

Nope. Sorry, but the Way LC communicates is transmission/reception of Pitch Bend data. As there is only one Pitch Bend control allowed per MIDI channel, each fader sends and responds on it's own channel. Hence, on the Mackie unit, you have 9 faders. These use MIDI channels 1-9 on one midi port. The only reason we "can't" do that is the PIC we use has only 8 AIN ports. Probably the confusion here is that the LC application has an option which selects which of the 8 available faders is to be the master (if any). From LC App main.c [tt]#define MOTORFADER0_IS_MASTERFADER 0 ; if set, the first motorfader acts as master fader[/tt] The default value is 0, meaning there is no master fader. So here's what you do: Get two Cores. First core does Faders 1-8 as channel faders. Second core has one fader only (fader 1), selected as the master fader. These two cores' outputs are merged into one port. Filter here so only one core will pass Sysex commands (for intitialisation call/response). Their inputs are split from one port. The host program will se one MCU, set up to have 9 faders, 9th fader as master. Only you will know the difference. All this said, if you are good enough with the programming, and can find a spare I/O pin on your core, it might be possible to skip all this and do it all with one core. This would be a somewhat substatial re-write of the LC app.

SmashTV is alive and well, he has been on chat a number of times over the last couple of days. He has been under the pump a bit lately. I'm sure he'll be back at it soon. (P.S.: If it is any consolation, I have a sizable order with him currently...)

The 9th pot is "not possible" because there is only 8 analog inputs on the PIC we use. The easiest way to do this is to use two cores for your master section. One core handles the first 8 faders, fader buttons and encoders/encoder buttons, The second core handles the master fader and all the control section buttons. This is what I (might) do on mine.

2 base are belong to us. I mean, 2 base boards for me please.

Hot diggidy! I am in!

wilba has chips? If Wilba has chips, I want wilba chips! Wilba, have you chips?

So it's not some potentially rack-mountable piece of kit that will look awesome and sound even more awesome. I think I've changed my mind about wanting one... :P

Good point slorrin. What is a P112? I suddenly seem to want something called a P112!

This is very interesting to me. I've been looking for a way to drive a click track for live drumming with a sequence. I have been using a headphone amp, connected to outputs from a USB/FW soundcard, via VLC (very loong cable) :P The trouble with this is it takes an output from the soundcard. THAT means that the sequence is in mono! One channel to me, one to front-of-house mixer. One solution is to get a soundcard with more outputs, but since most external boxes have MIDI anyway... this is ideal! I'll keep the headphone amp, but jam a core into it. Sweet!

If I understand correctly, you are talking about doing this in a master/slave configuration? Perhaps then, you could do this: [tt] +-------------+ +-------------+ +-------------+ | | == Midi Out via RS485 => | | == Midi Out via RS485 => | | | Master unit | | Slave unit | | Slave unit | | | <= Midi In via RS485 == |==(Merger)===| <= Midi In via RS485 == | | +-------------+ +-------------+ +-------------+ [/tt] For this, you would need full duplex RS485, as you are sending and receiving. This would work by turning your Midi Out from Master into a sort of "bus" for talking to all the slaves. Each slave would "listen" to the Midi Out from the master (via Midi In port), but add nothing to it. Assuming that you have several "slave" units, you would then have the monitor midi "bus" running through a merger at each slave unit, (where the slave is talking back to the master, but not listening to any slaves) If you could absolutely be sure that no two slaves would be "talking" at once, you could avoid the midi merger. One way to do this would be to only send a status update from a "slave" when that slave is requested by the master. The master then waits for the update (and/or a timeout period) before polling the next slave, etc. If you only have one master and one slave, you could ditch the merger altogether.

I was going to suggest MIDI to RS485. This is what I use everyday (DMX) in the lighting world. It's a differential, multi-point serial that holds up to 100kb/s at over a kilometer. (So MIDI's 31.25kb/s over 200m should be well-doable.) More's the point, it's three wires (sig+, sig-, GND) + SHIELD and daisy-chainable. Now, RS-485 is more of an electrical specification than a data protocol. What this means is you don't need to follow a standard method of transmitting (you don't anyway, it's your project, right? ;)) So, you could basically convert MIDI directly to RS-485 and back again, with no need to add extra start and stop bits, etc. Hope this helps.

Your best bet in terms of ease of programming and reliability would be to take a leaf out of old audio compressor design and use an optical coupler or similar strategy. The basic premise is that you: 1) connect a light source (ie an LED) to your audio signal (I would suggest using an op-amp buffer to avoid overloading your audio output, and to give you more juice to drive the LED). Also, the op-amp wants to be optimised so that your hottest signal will give it nearly +5v output. 2) physically coupled to this LED (and shielded using black tape or a small tubing sleeve, you connect an LDR device. 3) connect one lead from the LDR to ground, the other end to the analog input on the PIC. The pic would then treat the LDR as a voltage source, not too different to a pot or fader. This is the concept. You'll find it needs a little refining and experimentation.

Just sent a note to the winning bidder outlining the breach of IP laws and explaining that they could make their own for a great deal less than US$510... Maybe they'll realise they're being grossly ripped off! I sent them links to ucapps.de and to this forum thread.

beep http://tk421doyoucopy.ytmnd.com

I am very interested in 25 motorfaders, plus caps. thank you. Edit P.S. I'm not on this forum as much as I used to (as much as I'd like) so if I could get a PM when you guys have finalised details, etc... Also to remind me (I can be excruciatingly vague at times!)

Do you mean by this, that you had a MIDI LED flashing on your interface? If this is the case, I would strongly suggest you triple-check your MIDI I/O connections at the core. These connections are equally easy to get wrong, as right. :P If you mean you had acknowledgement from the host program that it was sending, check the above, but also check your interface settings.

Hi. Do you have your own lights to control? If not, you could be adding some severe headaches by changing from one venue to another. I say this because every manufacturer of DMX controlled moving light fixtures uses a different arrangement of channels. EG: [tt]"High End Systems- TrackSpot" (very old and clunky fixture) Ch 1 Pan (8bit) Ch 2 Tilt (8bit) Ch 3 Colour Ch 4 Gobo Ch 5 Motor Speed Ch 6 Shutter/Strobe Ch 7 Dimmer (Electronic control of incandescent lamp) "Martin- Mac2000 Profile" (much newer, full-featured unit) Ch 1 Shutter, Strobe, Lamp control functions (Strike/douse the arc) Ch 2 Intensity (Motorised mechanical dimmer/douser) Ch 3 Cyan level \ Ch 4 Magenta level - For three-field subtractive colour mixing Ch 5 Yellow level / Ch 6 Variable CTO (for colour temperature "matching" with incandescent lamp sources) Ch 7 Colour Wheel Ch 8 Gobo Ch 9 Gobo angle (MSB) Ch 10 Gobo angle (LSB ... Ch 24 Effect update speed [/tt] This means that if you set (say) a light to change colour and brightness with an 8th note hihat, this could work only if you continued to use the same type of fixture, addressed to the same DMX starting address. The DMX512 interface doesn't know or care what it is controlling. There is no command that says "change colour" or "increase brightness", only a series of 512 8-bit values. If you changed your setup, you'd need to "soft patch" to reference different DMX channels, otherwise your changing colour command could become something else. You would need to (at least) code a seperate PIC or AVR to do the DMX conversion. Bear in mind that while MIDI sends only the information that changes from one moment to another (note on, cc#x to blah), DMX512 sends a constant data stream, regardless of whether there is a change in state. Some equipment (I stress this, SOME equipment) can handle a temporary loss of data, by simply holding the most recent DMX frame in an on-board buffer. Other gear is less forgiving. Some dimmers will flicker, snap to zero and hold there, or just jump from one value to the next. Colour scrollers usually start shifting between servo points. Some moving lights do a software reset/hardware calibration procedure after even one missed frame!! Remember also, that the transfer speed of MIDI os 31.25kbps, whereas DMX512 is more like 250kbps *8(bits/channel) x 512(channels/frame) x 60(frames/sec). This is a lot of work for a PIC to handle. A much easier alternative is to find a lighting console which can be slaved to MIDI signals (most can), then just keep a channel of MIDI (ie MIDI channel 16) free for lighting, effects and show control. I've used a CP-10xt for this, which works very well. You could also use a Strand, a Hog, a GrandMA, the bank is the limit, really.

I would say that the 2pin- 2way switch is the better configuration. It just seems a little more, I guess, fail-safe. I'm sure that the PIC is stable and more than capable of remembering what state it was in at power-down, though. It really is up to you. If you need to save DIN pins, or to have the software application show you its configuration on the controller, then go with the pin saving toggle switch option. If you dont need to (which it seems you don't), then go for the wire-per-setting configuration. Since this is planned as a very specific controller, then the choice is absolutely up to you.

Good point. MIOS would really be overkill for an application like this. Come to think of it, most of the 18F family of PICs would be wasted on so simple a mod. My suggestion was for the simplest coding scheme for someone with limited experience. As far as I remember, the 800 series were a very simple interface, where you would enter a parameter number 11 - 88 (octal, not even close to 89, or even 64 parameters), then modify the parameter using up/down buttons. All that would be required here would be a PIC with a simple application. (this direction means this output for timeout period, multiple clicks mean this many discrete output toggles) The parameter numbers would be difficult to enter using an encoder, since I'm not sure how the panel was scanned. The other mods mentioned (filter cutoff, reso, DCO->filter) would all be performed in the analog realm, replacing onboard trimmers and fixed resistors with panel-mount pots.

All glory to the Hypnocube!! That is Hawt!

Here here!! I remember an article about the FM7 plug-in (either in Audio Technology or Sound on Sound) with an anecdote about the proportion of DX7s that went off to service technicians with the original factory presets still there, unaltered! I don't know if this is testiment to the great DX7 presets *snikker* or to the (inherent) confusion of FM synthesis! I don't want to tell you what you should or shouldn't do, and I know that FM synthesis is insane and difficult to comprehend, but stick to it, and just don't try to do things the same way as you do on an analog. FM synthesis is incredibly powerful, but if you try do do too much (ie, treat it like analog, LFOs and ENVs everywhere, full modulation of everything) it quickly turns to noise. Harsh noise. Take smaller steps, and FM can create incredibly lush and evolving sounds which analog just can't do. Good luck, and have fun! Sorry for the rant. **end of public service announcement** ;)

If these switches are wired so their positions send to different DIN pins, the modification to the code would be kept to a minimum. I'm not a coder yet (cause I'm yet to connect my LCDs-core-INs-OUTs together, and plough every waking moment from then on ;D ). My impression of how the control surfaces interpret things is as follows: 1) You close a switch. 2) The core sends a MIDI message or string dependant on the function related to that switch. 3) The core goes back to looking for a change in the control surface, or a MIDI message to interpret. ...so, if you give each switch position its own DIN, then: 1) You change a switch position, thus changing the state of the control surface. 2) The core sends a MIDI message or string dependant on the function related to that switch. 3) The core goes back to looking for a change in the control surface, or a MIDI message to interpret. The key word here is change. If you leave the switch in a given position, the core would still send the message only once. So all you need to do is choose a MIDI command to be sent by the switch. In terms of power down/restore, I'm not sure but I think the core sends the current state on powerup, so by using big 'ol clunky switches, you might reduce coding even more! As I say, I'm a bit of a n00bie, but this is my grasp of things thusfar. Anyway, there's nothing to be lost in playing around!