audiocommander

Wenn also noch nie was funktioniert hat, würde ich erst mal den Lötkolben oder das Lötzinn überprüfen? => Temperatur regelbar? Zu heiß? Lötzinn Sn60? Kalte Lötstellen? ...sowas lässt sich nämlich im Forum denkbar schlecht beantworten... und überhaupt billig ist der DIY nicht unbedingt, v.a. wenn es dann zu Schaltern, Tastern, Fadern und Encodern kommt... Du solltest bitte wirklich erst uCApps.de anschauen, dann im Wiki nachsehen und anschließend das Forum durchsuchen, bevor du eine Frage postest. Es ist irgendwie sinnlos, alles nochmal abzutippen :-\ Außerdem kann es bestimmt nicht schaden, die eine oder andere Information mitzunehmen, auch wenn du die im Augenblick (noch) nicht brauchen solltest.

There is already some information and the PIC16 Firmware available!

sorry für die (wahrscheinlich zu späte) Antwort, aber es sei hier der Vollständigkeit halber für das nächste Projekt erwähnt: klar gibt's die für OSX ;) Ich habe kürzlich SDCC als Binaries für OSX per Installer zusammengestellt (brauchst du aber nur für C) und GPUtils gibt's auch. Schau doch mal ins Wiki: http://www.midibox.org/dokuwiki/doku.php?id=application_development Hier ist ein Tutorial für Xcode, das auch die Installation für GPUtils und die Erstellung von Makefiles behandelt. http://www.midibox.org/dokuwiki/doku.php?id=how_to_use_xcode2_as_ide_on_a_mac Grüße, Michael

Bisher war alles in ASM, aber es wird vieles auf C umgestellt. MIOS, das "System" und viele ältere Anwendungen sind in ASM, aber es gibt auch sehr viele Applikations-Downloads in C. C ist für Anfänger definitiv der bessere Einstieg und gar nicht so schwer... Michael

Okay, das heißt, du redest nicht vom Kompilieren einer Anwendung, sondern willst die MIOS hex-Dateien in syx-umwandeln (= os_upload) ? Hast du mal die Syntax von hex2syx angeschaut? ("SYNTAX: hex2syx.pl <hex-file>.hex [<-device_id 0x..>] [<-bankstick <0-7>] [-os_upload] [-force] [-mem_64k] [<-debug>]\n" )? Ich denke mal, das könnte hilfreich sein ;) Trotzdem kann ich dir leider nicht weiterhelfen, wenn ich nicht die genaue Fehlermeldung kenne. Grüße, Michael

what about AIN 17-32 (or more precise 16-31) and the pins for the second AINX-module? Grounded these? If any bar of an unconnected pin is flickering, it is very likely to stray it's jitter to it's neighboured pins.

Es wäre sicherlich hilfreich, die Fehlermeldung zu posten, dann könnte man definitives sagen, aber hex2syx funzt auf jeden Fall. Hast du das MIOS 1.9 Skeleton verwendet? Das klingt eigentlich eher nach einem Programmierfehler oder die .hex-Datei ist nicht in Ordnung. ;)

But don't give too much weight on my unexperienced opinion here, I will post some more questions about this in the Bankstick Storage Thread... As I am actually thinking about the same issue (but different data, of course), I feel quite lucky having the possibility to chat with some mates. My girlfriend is not really enjoying that kind of talks ;D Cheers, Michael

Right, I should have noticed this :-X Now my window setup is stored, too :) Cheers, Michael

That's right. Just connect it to the spare pins on the multiplexed AINX-module. That's right; from the function overview: [tt]void AIN_NotifyChange(unsigned char pin, unsigned int pin_value)[/tt] This function is called by MIOS when a pot has been moved C_IN Pot number in <pin> 10bit value in <pin_value> So, pin contains the current pin (which initiated the call of the notification) and pin_value contains the current value of that pin; ranging from 0 to 1023 (switch closed if pin_value > 512) You get the 7bit value (0 - 127) by calling [tt]unsigned char MIOS_AIN_Pin7bitGet(unsigned char pin)[/tt], but to determine your switched state 10bit is fine :) It just has to be greater than half the value, then you know for sure it's closed and vice versa. Cheers, Michael

The point is, that it does not really matter if you dump to MIDI or dump to Bankstick. But you should implement this in a very, very early state, or you'll get the same results like me (= rewriting everything, because the data-concept is crappy!) What I've read from the "Concept of Bankstick-Storage"-Thread is to set up a data-structure on a bankstick-file, with all the needed address-ranges, so that no dump at all is needed, but just a command to write a specificic section of RAM to Bankstick or transfer that section via midi. My (too complex, double code size (!) and very slow) implementation has been to dump the data (buffer[32]; buffer[0] = param[1]; buffer[1] = param[2]... and so on...) and read it back in. I would split up the source-code in different files for steps and tracks. You should create a typedefinition for the steps. By creating a track, this track allocates its 16 step-variables. Know what I mean? Therefore you have a quite clear data structure, can easily edit and change and avoid additional code just to access this data. Best, Michael

Due to a restriction to SDCC, bitfields are limited to 8 bits! :-\ If you're interested in my personal opinion: forget about "nice, cleaned-up" variable access that requires nested pointer structures, multiplication operators for index access, arrays with more than 256 entries or other nasty things. Can't you split it up somehow in smaller data-chunks to avoid these huuuuge arrays? (eg 1 array for each bar?) :) (And besides: do you plan to store these arrays/data somewhen on a bankstick?)

right, no windows at startup. If I open them, they appear in their initial (small) size, top left of the program. I just tried with beta5_1 and it works as expected (sizes are restored to last state). Cheers, Michael

Hi meeshka, Actually, I like the Metal Look better, because the Aqua Look has the look, but definitely not the Feel of Aqua ;) I noticed, that the window positions are not stored anymore? Some of them are a bit small in their init states, but this is really peanuts... The overall impression is a lot better here on my mac :) Thanks! Michael I updloaded a screenshot (avbl 60 days):

Hi Rowan, to be honest, I can't remember clearly what I've sent you, but I'm pretty sure it hasn't been a template, but rather a quick un-cleaned-up working model. It's usually a lot more work to change a project in Xcode, than to set up a new one. So it might be best to start from the scratch. It's really just setting up two or three targets and pasting this script. ;) Best, ac

Taster + Encoder = DIN (4*32 Inputs) Potis = AIN (2*32) LED = DOUT (4*32), DOUTX4 bietet die Möglichkeit sehr viele LEDs über ein ShiftRegister anzusteuern. Wenn alle gleichzeitig mit 20mA leuchten, dann könnte das vielleicht zuviel sein. (Alle Zahlen ohne Gewähr, aus dem Gedächtnis ;) ) Hardwareseitig kein Problem. Wegen der Software musst du dir einfach mal die verschiedenen Projekte auf uCApps anschauen und vergleichen, die Hardware-Anforderungen (benötigte Module) stehen immer dabei. Das hat den Vorteil, dass du vollkommen ohne Programmierung ziemlich gute, schnelle und zuverlässige Applikationen bekommst, inkl. Bankstick Speicher, Motofader, LCD-Menu usw... Wenn dir das nicht ausreicht oder du was anders haben möchtest, kannst du dir deine eigene Applikation (die auf MIOS läuft) in C schreiben. Das kann sehr einfach sein (z.B. CCs senden) oder aber auch recht komplex, je nachdem ;) und in jedem Fall macht es sehr viel Spaß :) Grüße, Michael

you may have to pay for pointers by having to include a SDCC lib, which may blow up your code. If it can be avoided, I would avoid it. Unfortunately I have to rewrite my whole sensorizer class, because the data handling for bankstick storage got too complex. I oversaw this issue. I would prefer working with data that can be easily read from and written to a bankstick. (but I'm no C-Guru, remeber ;) ) Cheers, Michael

Hallo frank-owler :) Ich kann Dir empfehlen, die Einführungen im Wiki zu lesen: http://www.midibox.org/dokuwiki/doku.php?id=what_is_a_midibox http://www.midibox.org/dokuwiki/doku.php?id=introduction_to_ucapps.de http://www.midibox.org/dokuwiki/doku.php?id=questions_and_answers Danach sollten 75% Deiner Fragen beantwortet sein ;) Grüße, Michael

I love this midibox ;D It's looking fantastic!

great! :D This version seems to work a lot smoother on the mac (and is looking much neater). Thumbs up! :-* Thanks!!

well, I think you really should read the basic docs like: http://www.midibox.org/dokuwiki/doku.php?id=what_is_a_midibox http://www.midibox.org/dokuwiki/doku.php?id=introduction_to_ucapps.de (normally this is done before ordering ;) ) and maybe you should look out for a beginner's electronic book. There are plenty of them. To come back to your question: A switch is just ON or OFF, but your Midibox does nothing without a program (application). As there are dozens of different applications and the possibility to code custom apps, there is no unique answer. Look into the C-Skeleton, if you want to code your application by yourself (See http://www.midibox.org/dokuwiki/doku.php?id=application_development). You get notified by a toggle ([tt]DIN_NotifyChange()[/tt]), the value is submitted, too. Also, you can check the state of any pin at any given time. ;) Michael

OOhhhh, how sorry I am... This turned out to be a silly error!!! Checking the code again, I found that I wanted to get the state of a DIN-pin (checking the pedal), which is not available (of course, no DIN-board!). Bad code-reusing at big tomatoes on my eyes! Sorry to steal your time, but at least the typing helped me to think straight! :D

well, this is really strange. I just connected a fresh DOUT board and had the same issues. If the shiftRegister is enabled by [tt]MIOS_SRIO_NumberSet(4)[/tt], my sensorizer-code isn't executed anymore, but astonishingly the "normal" AIN-Pot->CC is executed. And moreover, the DOUT works as expected! While if the shiftRegister is disabled, the sensorizer-code works as expected but the DOUT won't do it (obviously because no SRIO active). I think that means it's a software issue and that my sensorizer calculations (which are a bit excessive, I admit ;D ) get somehow interrupted (aborted) by the SRIO, right? I tried to increase [tt]MIOS_SRIO_UpdateFrqSet[/tt] from 1 to 20ms, just to see what happens, but the behaviour did not change. I have three sensors connected to AIN 0-2, grounded pin 3 and four 10k-pots @ AIN 4-7. FYI I enclosed the relevant sensorizer code: void ZS_SENSORIZER_Sensorize(unsigned char pin, unsigned int pin_value) { unsigned char c = 0; unsigned int i = 0; unsigned char sevenBitValue= 0; // 0..255 unsigned int tenBitValue = 0; // 0..1023 signed int invertedValue = 0; // inverter var // read input if(sensor[pin].enabled == 0) { return; } // check pedal state if(sensor[pin].pedal) { if(MIOS_DIN_PinGet(BUTTON_AIN_PEDAL)) { // pedal is +5V => is NOT pressed return; } } // read 10bit input value tenBitValue = MIOS_AIN_PinGet(pin); // check threshold if(tenBitValue <= senseThreshold[pin]) { return; } // invert if(sensor[pin].invert) { invertedValue = tenBitValue - tenBitValue - tenBitValue; tenBitValue = invertedValue + 1023; } // + AINS if(pin >= SENSOR_NUM) { // send 7bit value sevenBitValue = tenBitValue >> 3; ZS_SENSORIZER_SendCC(pin, sevenBitValue); return; } // + GATE if(sensor[pin].gate) { // check timeout if(sensor[pin].read) { // reset gate timeout sensor[pin].read = 0; gateCounter[pin] = 0; } else { return; } // check gate threshold if( (tenBitValue < (lastValue[pin] + gateThreshold[pin]) ) && (tenBitValue > (lastValue[pin] - gateThreshold[pin]) ) ) { // save last 10bit value and abort last10bitValue[pin] = tenBitValue; return; } else { // save last 10bit value and go on... last10bitValue[pin] = tenBitValue; } } // + EXPANDER if(sensor[pin].expand) { // check smin threshold if(tenBitValue < smin[pin]) { sevenBitValue = 0; } else { // interpolate tenBitValue = tenBitValue - smin[pin]; switch(sfactor[pin]) { case 1: i = tenBitValue; break; case 2: i = tenBitValue >> 1; break; case 4: i = tenBitValue >> 2; break; // preferred case 8: i = tenBitValue >> 3; break; case 16: i = tenBitValue >> 4; break; default: i = ZS_MATH_Divide(tenBitValue, sfactor[pin]); break; } if(i > 127) { i = 127; } sevenBitValue = i; } } else { // don't expand, just read 7bit sevenBitValue = MIOS_AIN_Pin7bitGet(pin); } // scale if(sensor[pin].scale) { c = ZS_MATH_Scale_7bit(sevenBitValue, tmin[pin], tmax[pin]); sevenBitValue = c; } // send MIDI message ZS_SENSORIZER_SendCC(pin, sevenBitValue); return; } Any suggestions very welcome :) I'm a bit clueless right now...

Thank you for that quick answer; So this obviously points to a hardware issue... I'll try a fresh DOUTX4 module tomorrow morning... Seems like I'm really going to need this thing, because me (the greatest electronician of all {attention:irony!}) just found out, that the electric field of a 12V-translucent lightbulb creates enough interference to be detected by a skin resistance sensor with a grid of steel in a 30 cm range. That's a really interesting way to make music (you know, like Luke Skywaker with his light-sword...), but damn, I should've known this and that exhibition is on saturday... now I really need to exchange that fuc*in lightbulb with LEDs :P ... and if I'm using LEDs anyway, it would be sooo funky if I could get my app to control the lights... (I'll send pictures on this next week, because it actually would be the completion of my first MIOS based "Midibox" ;D ) So thanks again for the input on my output, have to sleep over it, keep you updated ... Michael

haha, I'm scrating mine, too (since a few hours now, already beginning to loose hair) ;D Thanks for your answer, stryd_one! I also tried [tt]4[/tt], even 8 and MIOS_SRIO_SRSet(4), but no luck so far... Maybe I have to add that I use J14 as DIN: [tt]// DIN Config MIOS_SRIO_TS_SensitivitySet(0x00); // TS disabled => Pin RD.4 (J14 Core) is free[/tt] But afaik this shouldn't be the problem? Or is it? Humm...