Jump to content

Durisian

Programmer
  • Posts

    160
  • Joined

  • Last visited

Everything posted by Durisian

  1. SWEEET! How do we create subdirectories?
  2. If you bought the PIC from smashtv it will already be uploaded. (and will say it on the chip). If not, you need to burn bootloader with PIC burner first. There's a link on ucapps somewhere for instructions....
  3. I recently used "size No. 6", used for screw type pcb mounts here's the rockby electronics link for a guideline http://www.rockby.com.au/catresults.cfm?stock_no=10342
  4. Yes. you can. But it seems a little excessive. In nuendo you can set up banks for a control surface, so theres no need for so many encoders. Remember you've only got 2 hands ;D. And it seems silly to me to add it to the top of the tascam if it's not really going to be a channel strip The displays on each encoder would be very difficult. Nuendo would not be able to send the name information to the 64e (only mackie control does this). Maybe... you could store the name of each CC/channel in the 64e, and use it for the display. But this would be a massive programming task, not to mention very difficult. You'd be better off writting a custom application. (64e can already display names on the main LCD if you use banksticks). Even if you did that, you'd need to devise a way to connect so many displays. Perhaps a led matrix?? This will also need a complex custom driver. An alternate thought.... For the big real desk feel Perhaps you could break a 64e into sections. eg. 12 encoders + 12 buttons for eq. 4 encoders + 2 buttons for compression. # encoders + # buttons for your favourate reverb. etc.... With 3 x 64e's you should be able to cover a large chunk of your favourate plug-ins
  5. Having only recently started in midibox land, the hardest thing I found was... i'm not sure how to put it.... direction... in terms of what you need to know. It's really overwhelming, and I struggled to get my head around even the basics, I'm glad I stuck with it!! Of course midibox is an open ended project, with almost infinite possibilities. So direction is not really possible. but here's 2c: -A definite introduction, top of the home page. What is midibox, what can it do. Including examples of applications and hardware designs, not all, just 1 or 2, and just the basics. Keeping tech talk to a bare minimum. -it opens with a 'please edit me'. It's irrelevant for newbs. It needs to be said, but maybe it can wait till later. It's pretty scary when you read that the first time and wonder if you really want to try and build a project. -The basics section needs to go under the MBHP section. Let's show people what it really is before teaching them to solder. Just a few thoughts
  6. You could. But you'll be pretty much restricting yourself to 24 static channels. There's no way you could make the 64e follow the tascam in mackie control mode... Having said that, your channel strips would be useless for plugin control compared to what the tascam can already do. You really need to emulate the mackie control c4 to be worth your time IMO. Good luck getting the protocol spec out of Mackie! Oh yeah, Nueno doesn't even support C4.... If it's a bigger channel strip your after. You could just build 1 big channel strip, with 1 64e. In nuendo, your tascam can run in mackie control mode. The 64e could be setup as 'generic remote', it's functions set to 'selected'. As you select a channel on the tascam, your 64e should follow that selected track. Giving you your channel strip.
  7. hehe! Yes, My tech talk is a little weak, so I didn't understand what that meant, but it did give me the idea. Thanks Stryd!!
  8. Ahhhh, I'm not sure whats going on with the c code. But the asm eeprom file. Needs to be an even number at the start of a line. eg. db 0x01, 0x02, 0x03 db 0x04, 0x05, 0x06 When uploaded will look like 0x01, 0x02, 0x03, 0xANYTHING, 0x04, 0x05, 0x06. 0xANYTHING I'm now starting to make progress with the asm method of bankstick uploading.
  9. Alright I've tried the above code with 2 different banksticks. And 2 complete different core boards. As far I can tell initially - identical results. The only thing that is the same, is the IC socket, cable and header that connects the core. Which I have checked with a multimeter and appears to be fine. Is there a test that I can do to check if a bankstick is wired correctly?
  10. Thanks Stryd, I look more into this on the weekend. 0x10 = 0xb0. Not nessacarily 0x20, there was just lots of them. Generally it seems random. This requires more testing on my behalf. It didn't like 'nnnn' had to convert all to hex (was using a mix). Sweet, use heaps of spaces... hehe thought about optimising, but I'm not sure I can optimse 30k of variables. There are 3512 variables that the user can modify direct from the floorboard :o The project is designed to be very flexable. I'm not sure it can be reduced and keep the same level of flexability. Yes, the best way to learn is to do it yourself!! Not discouraged, i've come a long long way from the first time I stumbled to this site 8-9 months ago. But for the first time I havn't been able to work out whats going on. Last night I set up a little application that writes data to eeprom, reads it back on the lcd screen, and then later reads it back again. First time the text shows up correctly, In the second loop, the first 8-10 entries are garbled, after that they are fine. possibly a wiring fault??? I can't see how though. I'll rewire it on the weekend. I wrote ths really quick... sorry it might be a little hard to follow. I only used the first 20 entries in this test void upload(void) { MIOS_BANKSTICK_CtrlSet(0x00); MIOS_LCD_CursorSet(0x40); // upload event_map MIOS_LCD_Clear(); MIOS_LCD_CursorSet(0x00); count = 0; for (i=0; i<20; i++) { MIOS_LCD_CursorSet(0x00); for (t=0; t<16; t++) { error = MIOS_BANKSTICK_Write(count + t, event_map[i].name[t]); } error = MIOS_BANKSTICK_Write(count + 16, event_map[i].status); error = MIOS_BANKSTICK_Write(count + 17, event_map[i].param1); error = MIOS_BANKSTICK_Write(count + 18, event_map[i].param2_def); for (t=0; t<16; t++) { MIOS_LCD_PrintChar(MIOS_BANKSTICK_Read(count + t)); } MIOS_LCD_CursorSet(0x40); MIOS_LCD_PrintHex2(MIOS_BANKSTICK_Read(count + 16)); MIOS_LCD_PrintHex2(MIOS_BANKSTICK_Read(count + 17)); MIOS_LCD_PrintBCD2(MIOS_BANKSTICK_Read(count + 18)); count = count + 19; MIOS_Delay(255); } count = 0; for (i=0; i<20; i++) { MIOS_LCD_CursorSet(0x00); for (t=0; t<16; t++) { MIOS_LCD_PrintChar(MIOS_BANKSTICK_Read(count + t)); } MIOS_LCD_CursorSet(0x40); MIOS_LCD_PrintHex2(MIOS_BANKSTICK_Read(count + 16)); MIOS_LCD_PrintHex2(MIOS_BANKSTICK_Read(count + 17)); MIOS_LCD_PrintBCD2(MIOS_BANKSTICK_Read(count + 18)); count = count + 19; MIOS_Delay(255); } } const events_t event_map[256] = // DO NOT CHANGE ARRAY LENGTH!!! { //{Name , Status, Param1, Param2_def } {"Volume ", 0xb0, 0x07, 4 }, {"Amp Gain ", 0xb0, 0x0c, 3 }, {"Amp Treble ", 0xb0, 0x0d, 3 }, {"Amp Mid ", 0xb0, 0x0e, 3 }, {"Amp Bass ", 0xb0, 0x0f, 3 }, {"Amp Vol ", 0xb0, 0x10, 4 }, {"Presence ", 0xb0, 0x11, 3 }, {"Reverb Mix ", 0xb0, 0x12, 3 }, {"Amp Type ", 0xb0, 0x13, 7 }, {"Fx Type ", 0xb0, 0x14, 13}, {"Fx Send ", 0xb0, 0x15, 1 }, {"Reverb Send ", 0xb0, 0x16, 1 }, {"Cabinet Type ", 0xb0, 0x17, 8 }, {"Reverb Type ", 0xb0, 0x18, 9 }, {"Noise Gate Level", 0xb0, 0x19, 12}, {"Drive ", 0xb0, 0x1a, 1 }, // 16- {"Wah Pedal ", 0xb0, 0x1b, 3 }, {"pre Effect Type ", 0xb0, 0x2c, 11}, {"pre Effect Par 1", 0xb0, 0x2d, 3 }, {"pre Effect Par 2", 0xb0, 0x2e, 3 }, ... etc...etc } This needs more testing... Sadly the real world is calling me away for a few days :(
  11. Hi Stryd. applications upload fine, only get upload errrors when uploading data to a bankstick. Cheers!
  12. Hi guys. I've been working on some floorboard software. The way it works is ain/din get information about what to do from an event table. in the event table are the midi events name, status, and a 'style' definition, eg, on/off or show a bar grapgh or calculate tap tempo, etc, etc AIN/DIN also have tables that tell them which entry to refer too. Plus a few other tables for various things.... I ran out of flash memory a loooong time ago, so now I'm trying to run the all the tables from a bankstick. I just can't get it to work. I upload some information direct to bankstick with a dedicated asm file like so... ;; preload file for BankStick list p=18f452 org 0x400000 ; "Name ", Status, Param1, Param2_def ;; 0- These are the CC's db "Volume ", 0xb0, 0x07, 0x04 db "Amp Gain ", 0xb0, 0x0c, 0x03 db "Amp Treble ", 0xb0, 0x0d, 0x03 db "Amp Mid ", 0xb0, 0x0e, 0x03 db "Amp Bass ", 0xb0, 0x0f, 0x03 db "Amp Vol ", 0xb0, 0x10, 0x04 db "Presence ", 0xb0, 0x11, 0x03 ... etc END When I upload with MIOS studio, every section gets a recieved less bytes than expected error!! I recall the information like this: just say pin_mapped = pin for ease of understanding. // snippet from AIN notify change for (t=0; t<16; t++) found_event.name[t] = MIOS_BANKSTICK_Read(0x0000 + (pin_mapped * 19) + t); found_event.status = MIOS_BANKSTICK_Read(0x0000 + (pin_mapped * 19) + 16); found_event.param1 = MIOS_BANKSTICK_Read(0x0000 + (pin_mapped * 19) + 17); found_event.param2_def = MIOS_BANKSTICK_Read(0x0000 + (pin_mapped * 19) + 18); found_event is later used to send a midi event and print data on the LCD. This works for the first entry of the table, but there seems to be extra bytes between lines. I wrote a quick bankstick scanner to check the uploaded data.... // In AIN nofity change { bankstick_offset_LSB = (MIOS_AIN_PinGet(0)) >> 2; // 00 - ff bankstick_offset_MSB = (MIOS_AIN_Pin7bitGet(1)) << 4; // 0000 - 7f00 MIOS_LCD_CursorSet(0x00); MIOS_LCD_PrintHex2(MIOS_AIN_Pin7bitGet(1)); // MSB MIOS_LCD_PrintHex2(bankstick_offset_LSB); MIOS_LCD_CursorSet(0x40); MIOS_LCD_PrintHex2(MIOS_BANKSTICK_Read(bankstick_offset_MSB + bankstick_offset_LSB)); // Show eeprom data } It shows at location 0x24 = 0xB0, 0x25 = 0xc0, 0x26 = 0x03 (which is line 2). By my calculations that seqence should start at 0x23... which shows 0x20... There's lot's and lot's of 0x20 in the eeprom, is there any significance? So as of the second entry in the event table, I get a garbled LCD, and random MIDI out behaviour For now I just want to ask if there something in the code above that could be causing the issues... Or should the code work. (a 'looks fine to me' would be much appreciated if it should be working) Thanks!!
  13. ......MIOS You access it with MIOS functions in your program
  14. I've worked in the sound and lighting fields for a long time.I have never seen DMX software that could speak mackie protocol. And I've used a lot of lighting consoles/software. And never seen a console with moving faders... well they'd actually be called 'dimmers'. Same thing, different field. do you really need fade... dimmers at all. Could you use encoders instead? with led's to show approximate position. Either way, it seems your building this for a fairly specific task. It migt be easier to write your own software. It's really not that hard. The chances of being able to extract the channel names from any dmx software is incredibly unlikely. However, it would be easy to create a static table containg the channel names, + midi info. With a little work, you could set up the table with potential channel names. And then each fader could be able to select from the table what it has to do. Happy to help you try!
  15. Ahhhhh.... I don't feel so much like a 'complete' idiot anymore ;D Thanks
  16. hmm.. cool will play with it some more Cheers
  17. hehe, event... nice catch, wrote it from memory... no typo's this time... i swear :) So... to keep it simpler if variable[5] = "abcd" MIOS_PrintCString(variable) should print abcd on the screen
  18. Is this a limitation of mios/sdcc? MIOS_LCD_PrintCString(event_map[found_event.entry].name); doesn't work, I think it was an incompatable type error when compiling I use this as a work around... which i believe the mios wrapper does this anyway. for (t=0; t<12; t++) MIOS_LCD_PrintChar(event_map[found_evernt.entry].name[t]); Just curious... might be one for the wiki
  19. Hi MTE yeah, i saw those. And will make use of them once my projects are little further along. But I mean more generic examples, that could be modified and used in many other projects. That a newb doesn't have to know who wrote the code or designed a specialty box to find it. Like on the ucapps C interface page On the hardware side - things like How to wire a trs socket to AIN so it's grounded when nothing's plugged in. Or Attaching an idc connecter to ribbon cable. Things that many people just know. But to the newb... "You want me to hit it HOW HARD!"
  20. Is there a place in the wiki to place such things? I've been working on various sections of code over the last 2 months or so. Most of which are very simple but took many many many hours of searching the forum/wiki. Writting, compiling. To work out exactly what commands I needed to use, what commands would work with sdcc, and to get them running. Things like typedef and struct, it took me many google searches, many times through the MIDIbox forum, and many hours just to get a basic idea. Now that I get it, it's so damned simple. I guess i just want a place to put examples, with descriptions that newbies like myself can understand. (while it's all fresh in my head, and i remember not understanding) If a place doesn't exist, we should make one! er... I'll make one? ;D
  21. hehe, i'm not a very good programmer ;D Have now built a new table containg name, status, data. Whole program is much simpler to work with now. Also altered the tap code slightly (principle the same, just written better) :) Behringer FCB1010 pedal board, it's not a midibox. The problem seems to be with clicks that are too fast. (code i was using was older than that posted, had used 120000 / bpmcountms, instead of 60000.) :-[ Can now tap at 120bpm nicely and down to much slower. But can only get as fast as arounf 220-250 and the random-ness starts. hmmm... this calls for a sequencer. ... ... ... hmmmmmmmmm, won't display over 255 - that can't be a coinsedence. edit: ALRIGHT! who's the joker that declared unsigned char bpm... I'll find 'em!!! :-[ Thanks heaps for your help guys!!
  22. Thanks Stryd. There is much more to the code, parts in this function rely on mproc_event_table. I think i'll create a new table in flash memory for overall simpler handling and useability. And then can move the code to MPROC_NotifyReceivedEvnt using a din had crossed my mind, but there are already 10 buttons on the pedal board. I only use 9. seems a little silly to add more when i don't use all that I have.
  23. thanks ac. Timer is stopped on the 2nd button press (if tapflag==1) And then reset and restarted once it has been displayed. If the bpm falls to 40 (signifiying there will be no more button presses), it also stops. ... I think.... ;D
  24. So for my first midibox i'm keeping the hardware side really simply, and getting into the programming side. This is link between my fcb1010 pedal board, and v-amp pro. To add another 8 pedals to it. And lcd display Anyway, I want to display the bpm the tap tempo function, now at this point it's a very basic design and can't ask the v-amp. It needs to come from the time difference between 2 button presses. Here's the code i've got; void Timer(void) __wparam { bpmcountms = bpmcountms + 1; bpm = 60000 / bpmcountms; //Stop timer if taken too long to press tap button again if (bpm == 40 ) { MIOS_TIMER_Stop(); tapflag = 0; } } --------------------8<--------------- From MPROC_NotifyFoundEvent if( evnt1 == tapcc ) { //is tap tempo cc if (tapflag == 1) { MIOS_TIMER_Stop(); //stop timer is it's running MIOS_LCD_PrintCString(" "); MIOS_LCD_PrintBCD3(bpm); MIOS_LCD_PrintCString(" BPM "); bpmcountms = 0; //reset counters bpm = 0; } tapflag = 1; MIOS_TIMER_Init(0x00, 10000); //start timer }; This almost works, except it doesn't display a consistant value for bpm. tapping at a solid 120bpm, results in values from 10 to 200. Any idea what i've done wrong, or perhaps an alternate solution.
  25. Hi, I'm new here, although I've been lurking for many many months. I just can't stop thinking about all the wacky controllers I could build!! Here's my first one, which a I need few pointers on..... In my project studio i work mostly alone. Control keyboard on desk. Guitar with V-Amp in one rear corner, Triton LE88 in the other. And also a Vocal postion in front of the keyboard. I have FCB100 Midi pedal board. Which when I'm tracking guitar, I can use to control cubase. I want to put basic transport control at each of the other 'stations' as well. I'm thinking core with 2x DINX4 and DOUTX4 on the desk which will feature extended transport control + 4x full parametric eq control on encoders. Possibly a fader. MB64e And then extending a box to each station with a DIN and DOUT only. So running J8 and J9 down a single cat5 cable (SC, RC, SI, SO, Vd and Vs = 6 wires, leaving 2 spare). I think I read somewhere that someone did this over 45 feet with a dout module??? Each extension box will have the same functions. To save on DIN/DOUTs Can more than one DIN/DOUT share the same shift register? by taking SI/SO at the input stage, and passing it directly to the output. Now that got me thinking some more (yep, that's bad) Would it be possible to emulate the shift registers id with hardware. Perhaps using dip switches to set it's place in the chain. Let's say I wanted to connect an extension to the extension boxes, that had controls specific to that area. That would leave 2 control sets that are different, sharing the same shift register id. SR1 - 8 Master > SR9 Transport extension box > SR10 Triton specific controller > SR9 Transport extension box > SR10 V-amp specific controller Any thoughts on how to emulate SR position in the chain? This could lead to creating 4 maybe 5 different control sets that can be placed many times, in many locations. Although there is a lot more room in my project to build more DIN's and DOUTs and user separate SR's I'm trying save them for future upgrade of the master controller. Without having to build multiple cores. All thoughts/ideas are appreciated
×
×
  • Create New...