Narwhal

In the Tascam, the ribbon cables from each of the control surface boards all connect up to the main controller board. I desoldered all of the connectors on the main board and soldered them onto a vero board that I drilled so that is would mount on the center screw posts.

This weekend I did a lot of work on this project. Follow along if you will.. I have been having power problems trying to supply the LED drivers from the core. Perhaps its because of some other wiring problem, or perhaps it's because all those LED on full brightness were sucking too much power. Either way, the main board in the Tascam contains a very compact 3A switching power supply and that's just what I need to make all of my power woes go away for sure. So I desoldered all the part and moved them to a vero board. Cheese eagle board file is available on request, but it's nothing special. I only made it so that I'd have a circuit reference once I desoldered everything.

Well the whole purpose of the first if: if (!((oldsensor1 ^ sensor1) & !(oldsensor2 ^ sensor2)) ) is to figure out of the wheel had been turned. It should be this though: if ( (oldsensor1 ^ sensor1) | (oldsensor2 ^ sensor2) ) I got it working last night and it is quite fast. There are exactly 512 state changes using a 128ppt encoder, when I spin the wheel a complete turn, I get exactly 512 on the LCD.. NICE! If I spin the wheel at the fastest, the highest MaxInc on the LCD I get is 0x30. This is how many state changes are counted during 1 timer interval. You need to spin the encoder as fast as you can to see what its limits are. By adjusting the timer delta to a shorter interval you can tune this value down. Longer timer intervals will cause this number to increase. The idea being, that you never want this value to get anywhere near having its high bit set with the fastest spin you can possibly put on the encoder. As you approach 0x80 you run the risk of your increments appearing to be decrements. But you can increase the timer interval so it interrupts less often to run the timer function. There is plenty of headroom right now to support even higher ppt encoders. I've attached the new main.c that is set to use an encoder that is attached to the pic's port C (J10) via pins RC4 (23) and RC5 (24). It's a lot like the encoder speed test, except that I don't yet have adjustments for speed. main.c

The code as posted does not work. It's not stable and totally goes nuts if the encoder isn't turning at all. But don't worry I'm working on it. I'll post code and results soon.

That's because x0xb0x does not equal Midibox. They are not related in any way. If you build a x0xb0x you can sell it for a million dollars if you can find someone to pay you a million dollars for it.

hmm no answer for this yet. The question sounds familiar, but a search I did when I had the problem didn't turn up any results. It sounds like the skeleton needs a definition somewhere that defines which processor type to build for. In a makefile maybe? For what it's worth, I use OSX too and I ran into a similar situation with one of the apps (can't remember which one though). But nearly every other app I've built has worked just fine. I have been using only the example apps so far and it's been working great.

This sounds a lot like a PIC that only has the bootloader in it and nothing else. I had one of these last weekend that I was dealing with. If you are sure that Smash uploaded MIOS and the MB64 app code to the pic, then you definitely should be looking at the LCD wiring. Use a multimeter to check continuity between each of the pins on the core to each of the pins on the LCD.. This should tell you if you have a good connection there. Don't panic if it turns out that all you have is the bootloader.. it's very easy to send MIOS, then send the MB64 via Midi using MIOS Studio.

somewhat like the mempot idea except using encoders and better manipulations I suppose.

Traktor 3's Native Mix files are essentially recordings of all the controls you interact with. It's a really great idea, I think I drooled a bit when I first played around with it. But are you thinking about applying effects to the movement data itself?

I'll be giving this a try myself as soon as I can, but my excel work shows that the directions need to be reversed: direction = 1; // Default to forward if (oldsensor1 ^ sensor2) direction = -1; I haven't confirmed this other than in excel, but it's something to keep an eye out for. For right now, Excel seems to indicate that it _should_ work :-) Anyone want to double check the excel work? The logical equivalent of XOR in excel is OR( AND(NOT(A),B), AND(A,NOT(B) ) EncoderXORtest.xls.zip

Can you post the new IP address? :P I can type numbers instead of the URL. We don't need no stinkin' DNS. ;D

You will need a midi interface of some type. A USB one will do. Then you connect the midi interface to the SID with 2 midi cables (IN and OUT). Then you use MIOS Studio to send the program (.hex) file to the synth. Specific details of the process are on the uCapps website... The button to get there is at the top bar of this screen.

How did you build the midibox sid?

The encoder speed test app seem to already set the update frq to 1. I don't think I can take it any lower :-) movlw 1 ; ms call MIOS_SRIO_UpdateFrqSet So does someone have a driver for encoders that are on port A, or do I have to write one?

More results: MIOS_ENC_MODE_DETENTED : Value only increases no matter which direction I turn. MIOS_ENC_MODE_DETENTED2 : Value only increases no matter which direction I turn. MIOS_ENC_MODE_DETENTED3 : Value wont increase or decrease no matter which direction I turn the encoder. EDIT: ** I've also removed the pull-up resistor on the DIN that this is connected to because the encoder performs it's own pulling-up and pulling-down. This gave no improvement at all.

I spent a little bit of time today attempting to use the high resolution optical encoder from my Tascam project with MIOS. The results seem not promising, so I wanted to check in here and see if anyone has any suggestions for something I may be missing to get it to work. The setup: I have the encoder wired to d0 & d1 of the 4th shift register of a SmashTV DIN module. On the reverse of the board I've added a small jumper to send 5v power over the unused pin of the input connector. This was necessary because the encoder needs power and ground to run it's internal logic. The encoders A output is connected to d0 and the B output is connected to d1. I'm using the enc_speed project loaded on an PIC18F452. Procedures: As I spin the encoder in either direction, slow or fast turning seems to makes no difference, the direction of the value will change directions even though I have continued to spin the encoder in one direction. It seems to change increment direction most often when I release to re-grasp for further turning, or pause for a bit. Questions: I'm guessing that the rate of change of the encoder is either so fast for that MIOS misses some changes, or the pattern is not equivalent to the NON_DETENTED setting. To me it appears to be fine for the NON_DETENTED setting. Any suggestions for what I might try? Spec and pictures are in the part forum topic. Video of the problem here: mfuBxhUT3Mc

A single mixed main out does exist on the 6582. It's a small jack above the power switch. There are resistors near the output jacks that need to be adjusted down in value to get a decent mix volume. I'd suggest a value, but I'm still working on getting mine to sound right... so you might want to hold off on soldering those in. See the section in the wiki titled "What’s the purpose of the J70 header?" for more info.

Nice things deserve being finished because anything worth doing is worth doing right. So don't let your time constraints bum you out so much. You can easily come back to it and make it work perfectly, and we will help.

I'm in for: 55 3FTL6 "Quiet" +55 1E.09.6 Black +10 1S11.16.0 Clear

The boards arrived out here in California today. They look nice Ulta. Thank you for all the work to put this order together.

Mine came from a company called Digital Dream Sound Studios in Burbank via eBay. I haven't yet made it to an SRL show, but I've known about them for many years. That's really cool if yours came from him. You should have had him burn the $#!t out of it before mailing it to ya :-) I guess the $50 optical encoder that's in there might not have survived in that case, so it's probably better that you didn't.

I think your new mini design needs 3 more knobs: master volume, headphone volume, and headphone mix. I have a vestax vci-100 which has pretty much all the same controls as your design except for those three knobs. I find headphone mix and volume essential.. master volume is more of a set and forget. Lookin good though!

While I don't know anything about where or if you can get the schematic file, I do know about C5 and LED1 because I asked the same question here before. Those items are connected to a ground plane that is shown by the dashed outline in the image. Sometimes people also hide the ground planes in the images they post.

Hmm seems to work both ways now. Perhaps it's my power gremlins playing tricks on me. Seems like power is the next big thing I have to deal with. Today I began attempting to get the hi-res optical encoder working. I have it wired up and it looks like it's putting out the correct pulses. Unfortunately before I did that I chose to switch over to the sm_fast version of the button scan matrix code. The sm_fast version main.c Init() function contains the following lines: // initialize the shift registers MIOS_SRIO_NumberSet(0); // DONT USE THE MIOS SRIO DRIVER!!! Does this mean I can't use the MIOS SRIO driver at all?? Or can I tweak some pin values to move around the fact that another driver is dealing with a few of the DIN and DOUT shift registers?

I'm taking a stab that these three lines should sufficiently say that I don't want to use AIN features at all: MIOS_AIN_UnMuxed(); MIOS_AIN_DynamicPrioSet(0); MIOS_AIN_NumberSet(0);