audiocommander

Hi Tom, the main credit goes to TK, of course, who provided us with such a nice template :) IIRC I changed unsigned char mclock_ctr_measures; // counts the measures (up to 65535) to be an unsigned int ...and I think there were one or two other minor issues, but I can't remember what they were. I attached a zip with the modified mclock files and hope they are of some use to you. The master/slave stuff doesn't really take away much space nor processing power (IMHO), but it's a nice feature, where at least something is coming out of the box, even if there's no midi-in attached... cheers, Michael Edit: Whoops, I deleted an important define (wanted to keep away the unnecessary work-in-progress-stuff) in ACSyncronizer.h has to be added: [tt]#define MASTER_IS_ALIVE_COUNTER 4095 // detect timeout at MIDI_CLOCK receive[/tt] ACSyncronizer.zip ACSyncronizer.zip

as already stated, sync (quantizing) is only enabled for the handtracker (AIN), 'cause it's no buffer-mechanism but a timed trigger-action. I got to do some urgent work now, I'll record the osc without env as soon as I find some free minutes... In the meanwhile for all people trying to catch up all these posts lately, this is the important stuff: - v0.2.4 beta http://www.midibox.org/forum/index.php?topic=2870.msg63685#msg63685 - technical demo (synth sounds, quantising, harmonising, experimental handTracker modes) regards, Michael

Here's a raw demo video (a bit blurry, but better than nothing), focusing mainly on the synth/envelope/subtractiveSynthesis features:

hey, that sounds great :) I am currently working on an alteration of mclock with a master/slave mode (that means, if a midi-clock signal is detected on the input, it syncs to the clock; if not (anymore) it falls back to master-mode). quite simple, but working good. I also detected some minor problems in mclock that could lead to buffer overflows. If you're interested I could PM you my current working version. If I can assist or help with this project, or just share thoughts, I'd be happy :) A simple 4 bar recording/looping/syncing tool sounds really great to me!! Cheers, Michael

There are also START, STOP and CONTINUE messages ;) Amon Tobin sounds very nice...

Hi Simone, just a quick mentioning: 0xF8 is no SysEx SysEx is a SystemCommon Message, whereas the Clock is a SystemRealtime Message ;) http://www.midibox.org/dokuwiki/doku.php?id=midi_specification http://www.midi.org/about-midi/table1.shtml http://www.midi.org/about-midi/table2.shtml and of course: http://www.borg.com/~jglatt/tech/midispec.htm Maybe a clear table helps you understanding all these strange numbers like it helped me :) Regards, Michael

Hi Rio, that's okay, I fixed that (dl is the same as before, but new contents) There's an ACSyncronizer Class with auto master/slave mode (slave if clock signal on midi-input detected, falls back to master mode if clock stops). The handTracker is syncronized to 1/4, 1/8, 1/16 or 1/32 note values. That's one of the features I'm absolutely proud of and I will improve this concept for the next sensorizer version. Maybe a standalone MB Quantize Box, too (someday ;D ) I recorded a video yesterday showing the LCD to see and hear the possibilities; going to upload that on youtube... I'll post a note as soon as it's online! It's normal if ACSYNC_GARBAGE_SERVICE is enabled and there are 32 bars in between (that's a noticeable delay). However, it's not normal if you can hear one or more Sonar Pings on startup followed by a neverending gibberisch blahblah. I do not hope for you that this is what I fear it is: you probably found out the downside of the PIC16F88 firmware version 1.0 / 1.1 and what made me cry and nearly sink in despair for a whole month – Could you please do the following test: if the SJ behaves in that way (one or more sonar pings at startup, then continuous grababbeling): - leave it on - connect by RS232 to the pc and start Phrase-A-Lator - set the baud rate to 19200 (I think it's the connection-tab) If it works again, it's the startup-baudrate-sync bug, where the PIC16F88 is sending the baud-sync signal too fast and the SJ is missing that. The SJ then operates with 9600 baud while the PIC18F452 sends with 19200 baud... that's what you hear... I would not wonder if this bug finally found you, too (I would have wondered why it only should hit me). You can also try to switch the box on/off multiple times, but it will become worser, you have my word for that. With the firmware 1.2 I never experienced this behavior again (until now... knock on wood... knock...knock...knock...) I will order at Reichelt in the next weeks, I have not forgotten sending you a new PIC16 with fw 1.2 Cheers, Michael

hurra! :D

Hallo Rio, also, nein, unsere Vorstellungen unterscheiden sich, denke ich, grundsätzlich nicht – solange nicht unnötig IIC-Nachrichten generiert werden, die leicht zu einem Pufferüberlauf führen könnten. Wie schon gesagt, ich habe beim Versuch, die Sachen zu übernehmen, irgendwann die Übersicht verloren. Es ist ja immer schwierig Code von anderen zu verstehen... Wenn du mir eine Version mit klaren Benennungen und abgekapselten Funktionen geben kannst, werde ich das sofort diskussionslos übernehmen. Das Problem ist halt einfach, dass ich (z.B.) nicht genau weiß, was mit env_slide, env_mod, env_mode, env_state auf sich hat. Es fehlen auch Kommentare an der Deklaration, die das detailliert erklären würden. Verschärft wurde das ganze Dilemma noch, da ich gerade beim ENV eine vorher von mir mies programmierte und buggy Stelle schön neuprogrammiert habe (durch das saubere Bitfeld): Und das meine ich dann auch mit "redundant": Du hast einige meiner Bugs gefixt und ich habe diese nun noch einmal weitestgehend detailliert überarbeitet - dadurch ergeben sich Überschneidungen: - ENV Settings (alt: HalfEnveloped for OSC4/5 ging nicht, du hast's gefixt, ich habe die ENVCtrl komplett neu geschrieben; damit können jetzt alle ENV settings in einem Bitfield gespeichert und auch auf einen Rutsch übertragen werden) - Harmonized Input (alt: ich hatte einen NOTE_OFF-Bug, du hast beim Fixen einen NOTE_ON-Bug daraus gemacht; auch hier habe ich das fixen können und habe aber irgendwo gelesen, dass das Volumensetting deaktiviert ist? ...dachte ich zumindest, sorry falls ich mich hier getäuscht habe). Und dann bin ich ja auch nicht perfekt; manchmal fliegen alte Definitionen rum oder es gibt auch bei mir nicht ganz 100% exakte Namen. Aber wir müssen das halt irgendwie vereinheitlichen... ich bin da auch für Vorschläge oder Kritik offen. Schau dir einfach mal in Ruhe die neue Version an (v.a. meine Bugfixes). Ich fände es super, deine Erweiterungen zu übernehmen, aber ich habe einfach keine Zeit, den Code so detailliert zu analysieren, dass ich alles verstehe und dann neuzuprogrammieren... und das ist ja auch nicht Sinn und Zweck der Sache. Da ich noch länger am Quellcode entwickeln möchte, muss ich darauf achten, dass alles ordentlich benannt und wohlüberlegt getrennt ist, damit man sich in zwei Jahren auch noch auskennt. Wenn alles super läuft, könnte ich z.B. nur durch die Anpassung der Kernfunktionen einen Port für den SoundGin machen :) ...aber das ist noch Zukunftsmusik... lg Michael ps: ich habe gestern ein kurzes Video aufgenommen, das spiele ich heute irgendwann im englischen Forum hoch; das zeigt auch die Sync-Features.

1. To deactivate the AINs, do not use AIN = 0, instead use KII_AIN_ENABLED = 0 in main.h There was an error, too in this setting, but without this option, there are the best features missing (handTracker matrix and syncronizing stuff) ::) Anyway, I fixed it. You can download the files again. 2a. The phrases shouldn't be altered. As I already mentioned, I have to look into this further: What I can say now, is that this does definitely has nothing to do with the uploading process, it most probably happens when operating with the handTracker mode set to the experimental synth channels 11 to 16. 2b. What you hear is the auto-garbage collector that resets the SpeakJet each 32 bars and then enounciates the first phrase and one of the phrases 2 to 16. This is to keep the device all time working, collect hanging notes; performing an overall cleanup. You can deactivate this option by ACSYNC_GARBAGE_SERVICE in ACSyncronizer.h 3. The current version is optimized for a 2x8 LCD. The 2x16 is not yet adapted. Regards, AC

I recommend http://sketchup.google.com/product_suf.html for 3d modelling. It's definitely the easiest and most intuitive 3d program I ever stumbled upon (costs nothing; restricted export formats though - no dxf export or similar -, but good enough for exact planning, nice shadings, too – and lovely sketchy designs). I tried blender, too: did three tutorials... now I can flip around the inteface-menus like a pro, but am still too dumb to draw a simple rectangle :P :-[ IMHO inkscape is more like corelDraw than freehand; not bad though... and there's CanvasX (not free, but far less expensive than overpriced stuff like illustrator) http://www.acdamerica.com/products-x/x/default.html cheers, Michael

hi, If you cannot find Serge's SysExBox, use MIDI_OX to transmit the syx-file. MIOSStudio unfortunately can only transmit .hex-files If you want to change the sourcecode, you must do it with MPLAB, because MIDIO is written in ASM. Recompile as described under MPLAB at uCapps.de Upload the hex with MIOSStudio OR the syx with MIDIOX. If you need to convert a .hex file to .syx you will need Perl (if it's not already installed on your computer). That's what activePerl is for. for an understanding of the bootlaoder, MIOS and your program see the graphic here: http://www.midibox.org/dokuwiki/doku.php?id=mios basically it's all described well on http://www.ucapps.de Regards, Michael

also, ich hätte Interesse an 8 Stück, wenn noch welche verfügbar sind... Grüße, Michael

I just packed up a beta version. There is still no DIN-Input, but I overworked lots of things. Before releasing, I'd like to know why the first phrase sometimes gets overwritten. I implemented an input buffer control (connected SJ:D2 to Core:J14), and of course there's the handTracker. And there are 16 playmodes, modes 11 to 16 are experimental and involve mixed speech/synth control by the handTracker. You might test this by touching the AIN-pins of the Core ;D More "premium"-features: - auto-sync (auto master/slave detection; midiClock recognition) - harmonisation with 20 scales included - optimized subtractive osc-synthesis & fixed envelope settings Also included is a setup for a KORG microKONTROL, so if you have one, you're ready to rumble immediately :) Version History: mbhp_iic_speakjet Firmware (PIC16F88): v1.0. 2006-04 X First version by TK v1.1. 2006-11 Reduced input buffer, compiled by mess v1.2. 2007-03 X Fixed baud bug that prevented right baud sync on some startups (by AC) Thanks to stryd_one. kII main application (PIC18F452): v0.1.0 2006-05 First version v0.1.1 2006-06 MIDI Control Interface for MSA v0.1.2 2006-06 SCP Support v0.1.3 2006-08 Added new Wrapper (MIOS_HLP_Dec2BCD-Fix) minor fixes v0.1.4 2006-11 saved 4 kb by overall optimisations (esp. note2freq handling) fixed note-off bugs, merged with note-on channel functions assignable by definitions improved midi-input handling reduced buffer on mbhp_iic_speakjet_v1_1 (thanks to mess!) v0.1.5 2006-11 X vowel/lconsonant interface categorized by position in mouth first public release v0.1.6 2006-12 added AIN sensorMatrix: handTracker added ACSensorizer class with minimal config v0.1.7 2006-12 improved phoneme maps, added opening/closing consonants fixed a bug that prevented consonants to trigger by channel notes v0.1.8 2007-01 added new handTracker with merged sensorizer to save space and gain better results by a specialized sensor matrix v0.1.9 2007-01 fixed deadband-bug, added speed detection, improved sensor matrix v0.2.0 2007-01 added ACSyncronzier (based on mclock; added MASTER/SLAVE mode, initializes in master mode, switches to slave if MIDI_CLOCK detected, exits slave and switches back to master on MIDI_CLOCK timeout) Syncronizer Features can be disabled => Gesture Polling on AIN if enabled gestures get polled by Syncronizer within 1/16 note values improved sensor readings & gesture detection v0.2.1 2007-02 implemented linearizing algorithm and therefor greatly improved readings! fixed, simplifyed and improved gesture detection fixed syncronizer measure-overflow fixed mclock bpm local variable shadowing simplified cm-conversion and opening state (removed open bug) v0.2.2 2007-02 added manual transmission mode to reduce IIC_start/stop transmissions added UpdateLock() to prevent abortion of played phrases experimented with buffer clearance for smoother vowel-smearings improved tongue (is now roll) improved release detection with higher resolution in the lower range auto-presenter: hard-resets SJ every x measures (garbage cleaner) & triggers startup message on idle) -> see ACSyncronizer.h: CTR_MEASURE_MAX fixed Sync-Bug where triggers did not work inside the Timer() function quantized events now poll properly each x clockTick (1/4, 1/8, 1/16, 1/32) re-added bending (related to speed) ACSim_Console or ACSim_Handtracker now work both within the same Xcode project ACSim_Handtracker now contains a GlobalTracker panel to watch variables Harmonizer defaults to H-Spanish (international: B-Spanish) added randomizer to decouple the consonants from jaw opening v0.2.3 2007-03 cleanup, added cycling startup message option checked with new handTracker hardware and Amp Circuit v0.2.4 2007-04 X fixed a bug where the SJ could stop enunciating when speed dropped to 0 cleaned up and reordered MIDI Output of sensor matrix values added ACMidiProtocol to enable automatic harmony change requests quantize values (ACSyncronizer) can now be changed dynamically by MIDI the Speakjet now does a hard-reset each x bars; improved startup messages after resets (added small delay). This should be quite secure for exhibitions. first experimental speech output modes (additional OSC manipulations) added random harmony function added Buffer Half Full Check and IIC transmission lock (SJ:D2 -> Core:J14) fixed & improved OSCSynthesis (partly based on suggestions by RIO, thnx) rewrote ENV control and added ENV options for OSCs 4/5 fixed NOTE_OFF bug when harmonising synth input added bpm set tempo by midi cc (60..187 bpm); only accepted if master X release versions [/code] download kII 0.2.4. beta (pre-release) http://www.audiocommander.de/downloads/midibox/kII_024_070410.tgz (717 kB, sources included, of course) Any Feedback welcome! Cheers, Michael

Hallo Rio, ich hoffe, du genießt noch deinen erholsamen Urlaub :) (bräuchte ich auch mal) Nachdem sich nun das Release 0.2.4 der nächsten kII-Version nähert und ich kräftig am bugfixen und Code-aufräumen bin, habe ich mir nun in Ruhe mal deine sämtliche Erweiterungen angesehen. Zuerst wollte ich alles übernehmen (mergen), aber das konnte ich nicht, da deine Erweiterungen teilweise redundant zu meinen Funktionen und bereits existierenden Variablen sind und so einige Funktionen überflüssig würden und es auch sehr viele Überschneidungen in bestimmten Bereichen gibt. Nachdem ich drei Bugs gefixt habe, auf denen ein Großteil deines Codes basierte, bleibt nun nicht mehr so richtig viel übrig, das ich übernehmen könnte: + Envelope Settings Die Option Envelope half-on/off für OSC 4/5 hatte ich im ersten Release übergangen; ich habe das nun sauber neu programmiert; d.h. ich habe nicht deinen Code verwendet, sondern ein Bitfield angelegt und mehrere Controller, mit denen man die verschiedenen ENV-Optionen entweder direkt setzen oder weiterschalten kann. + Hanging Notes (NOTE-OFF Bug) Dieser Fehler hing mit der Harmonisierung zusammen. Ich konnte das Problem lösen; es funktioniert jetzt einwandfrei. + Knackser im Anschlag/Lautstärken-Einblendung Ich habe auch diesen "Effekt" beseitigen können (ich möchte es fast nicht Bug nennen, weil ja nicht jede Note, sondern nur einige wenige betroffen waren) : Das ganze lag nicht am schnellen Setzen der Lautstärken, sondern am Envelope! Jetzt wird der ENV nach den OSCs gesetzt, und das Knacksen ist weg. Dadurch gibt es auch keinen Grund mehr für deinen Workaround, die Lautstärken einzublenden um so das "Knacksen" zu vermeiden. Diese Lösung fand ich allerdings auch aus performancetechnischen Gründen nicht so gut. Zumal ich den Verdacht hege, dass das bei dir entstandene Krachen in den höheren Bereichen auf einen Buffer Overflow gründen. Bei mir trat das das von dir beschriebene Problem in höheren Bereichen für den ENV OSC4/5 nie auf. Außerdem habe ich einen Puffer-Überlauf-Schutz eingebaut; speziell mit dieser Funktion ist es noch wichtiger geworden, mit der Anzahl der gesendeten Werte hauszuhalten. Dazu kommt, dass ich mit dem ACSyncronizer (midiclock "Umbau") in der neuen Version einen zeitkritischen, timingbasierenden Auftrag für den PIC habe; da muss ich aufpassen, dass alles mehr oder weniger gut getimed ist. Auch noch erwähnen möchte ich, dass ein weiterer Nachteil deiner Implementation darin bestanden hat, dass das Velocity Setting der Note-On Anschläge komplett ignoriert würde. Für dynamisches Spielen finde ich das allerdings ziemlich wichtig und sinnvoll. + Ungestimmter ENV Dein Ansatz mit dem in der Frequenz nicht angepassten Envelope klingt zwar einigermaßen gruselig; hat jedoch was interessantes :) Ich werde über eine Implementierung nachdenken... gibt es hier noch jemand anderes, der für soetwas Verwendung hätte (also eine OSC-Synthese mit ungestimmten Envelope)? + OSCSynthese Abgesehen von der Schleifen-Optimierung habe ich mit deinem Code in diesem Punkt leider ein grundsätzliches Problem, da durch die Änderung die Subtraktive Synthese keine solche mehr ist. D.h. der Clou dieser Methode liegt darin, dass ich von der Grundfrequenz ausgehend, mehrere Harmonische berechne und dann bestimmte Harmonische in ganz exakt definierten Lautstärkenverhältnisse anordne (Subtraktive Klangsynthese). Aus diesen durch Lautstärke strukturierten Harmonischen Sinuskurven ergeben sich neue Wellenformen (Saw, Square, Triangle). Diese Wellenformen haben *nichts* mit dem Envelope zu tun; es ist etwas vollkommen Neues, das nur aus der Mischung der Harmonischen entsteht. Mit deinen Änderungen im Lautstärkenbereich wäre diese Methode deshalb nicht mehr funktionsfähig. Fazit: Ich könnte mir vorstellen, dass du (anstatt aus der Subtraktiven OSCSynthese etwas zu machen, das sie nicht ist), eine neue, auf einem gänzlich anderen Prinzip aufbauende Soundsynthese entwickelst. Das würde ich dann jederzeit in ein Release übernehmen – vorausgesetzt, es ist einigermaßen einfach zu implementieren, also hat sinnvolle Variablen/Funktionsnamen, ist funktionell gut vom rest abgegrenzt und dadurch gut verkapselt. Für sowas sollte dann auch eine neue SJCH_Channelvariable definiert werden, die dann diese Funktion zu einer macht, die per Midi-Kanal ansteuerbar ist. Also: - eigene SJCH_Channelnummer: z.B. SJCH_RIOSynth - eigene Funktion: IIC_SPEAKJET_RioSynth() - eigene Variablen: rs_env_mode, rs_whatever usw... Es sind im Augenblick ohnehin einige SJCH_Cannels mit ziemlich überflüssigen Funktionen belegt (SJCH_Consonants z.B.), da kann gerne noch was sinnvolles kommen... Das kann ich dann mit drei Copy & Paste Vorgängen übernehmen, ohne mich erst zeitaufwändig um die Implementierung kümmern zu müssen. Es ist nämlich auch ziemlich schwierig fremden Code zu integrieren, der über mehrere Dateien verteilt ist, wenn ich nicht 100% durchsteige was da exakt passiert und die verschiedenen Variablen sehr ähnlich benannt und in ihrer Funktion nicht unmittelbar zu identifizieren sind: z.B. env_waveshape, env_state, env_mod, env_slide, (envelope) mode; dazu kommen noch env_freq und env_value. Es ist echt schwierig da noch durchzublicken... Außerdem ist es nicht optimal, wenn eine Basis-Methode (IIC_SPEAKJET_ENVFreq), die von anderen Funktionen benutzt wird, verändert wird. Besser, diese (experimentellen) ENV-Änderungen eigens in einer separaten Funktion unterzubringen... so, wie du es mit IIC_SPEAKJET_OSCPlay und _MultiPlay gemacht hast. Alles in allem danke ich dir für die vielen guten Hinweise. Ich werde in den nächsten Tagen im englischen SpeakJet-Thread eine Beta veröffentlichen; es wäre nett, wenn du mir Bescheid gibst, ob die mit deiner K64-Tastatur funktioniert. Erst wenn ich dein Feedback habe, werde ich das Release is Wiki setzen (und wie immer: keine Eile ;) ) Viele Grüße, Michael

Dear midiboxer, please post new topics in this area of the forum only, if your question or information is related to a User Project: http://www.midibox.org/dokuwiki/doku.php?id=user_projects A "User Project" means, that your topic is about an unoffical new application based on MBHP and/or MIOS, developed by one or more midibox user(s). In contrast, a box running with an adapted (or unaltered) version of MB64/MBSeq/MBSid/MBWhatever... is not a new user project! In those cases, there are better places to post your questions/ideas (for example) : - Midibox HUIs (for MIDIbox64/64E/LC/MM/KMK) - Midibox Design Concepts (for new ideas, new HUIs, using existing applications) This also applies, if you'd like to know if this or that is possible, or if you want to discuss fresh ideas but your project is very far away from releasing any files/data. If you are developing a new application and it's likely you will release your project, feel free to post :) ...or if you have any questions about existing User Projects, your questions are welcome, we will all try to help and support you as we welcome any kind of feedback :) Please try to keep all information about your project (pictures, source, etc) on-site - attached in forum posts or on the WIKI because <broken-record>offsite doco bad</broken record> Cheers for reading this, (just trying to keep the information overviewable) Michael

http://www.edrum.info/

thnx to Smash for moving this one to the userProjects section :) This is one of the most promising projects to me and I'm really looking forward to build my first "messy" soundcore ;D hehe... Cheers!

Hi Kris, I try to keep some informations about sensors on this page: http://www.midibox.org/dokuwiki/doku.php?id=sensors just quick links, but they may trigger some ideas and imaginations ;) Cheers, Michael

This is a great idea! Remember exploding brains, when we discussed buffering techniques? Now, it's stunning, that I came to the point working totally without buffers for the next sensorizer; actions just get triggered by clocks. So if it's not the right time, nothing happens. Well, I guess this principle is not really extendable to other projects, but I cannot believe how long I thought about complex buffers before this strikingly simple idea hit me. Now you're talking of nonlinear clocks and I feel there is something similar going on that is definitely worth exploring :) I wouldn't freeze any idea while being in development status. Normally some features get dropped before release 'cause they don't work anyway, so why restrict your imagination now? You're no company, you have no customers and if someone elses hobby-vX is exploding in experimental mode it's not really your problem (is it? ;D ) It sounds like a simple idea with extreme effects. And I like simple ideas with great impact very much. Cheers, Michael

Hi bosone, nice to hear from you, have read about your breath controller when I was a newbie here ;D This seems to be the right project for you. However, there are only 8 sensors supported per module. I recommend 4 (depending on the power usage of the connected sensors and the frequency of the produced messages). With 4 distance sensors, the box is running charmingly, the power regulator does not get very warm. However, with 8 distance sensors, the power regulator gets hot. If you mix active and passive sensors (distance sensors are active) or have only passive sensors, 8 should be no problem. The sensors get directly connected to the Core. The sensorizer has been developed to avoid exactly those problems like flickering, low range threshold, limited range, etc... :) 8) About the trackpad: you need to find out how to connect this. Without knowing the exact specs, I cannot help you with this. You may search the forum; there are some topics around that will help you. Basically you should find out if you're dealing with either resistance based or capacity based technology. The first one might be easier to connect (2 Resistors, X/Y), the second one has its advantages, too, but may be difficult to connect. You can find the "D-Beam" if you search the web for Sharp GP2Dxxxx IR (Infrared) Distance sensors. Conrad sells them for about 35,- EUR in Germany (unfair pricing), Farnell has them for about 11,- EUR (normal price): http://it.farnell.com/ ...I've also seen them for 8 to 15 $ in some US robotic shops. Be careful and read the specs before you buy: there are digital and analogue types, don't take the "digital" ones, they just provide a binary ON/OFF status (eg. ON when something is near and OFF when there's nothing in range). You should build the ACSensorizer 0.4 (basic). It's basically the same as 0.2 (stage) but has an easier control menu. The HUI for 0.2 won't be developed further, with v0.4 you'll have a future proof box and can await firmware updates from time to time. I'll release the first 0.4 firmware soon. If you want to check out the software, I can send you a beta version. Although you can use the 0.4 beta, Harmonizing and Syncronizing features are not yet fully implemented, but both work fine in the upcoming kII (SpeakJet) project, which I will finish first. After I released the SpeakJet files (Priority 1), I'll update the Sensorizer Sources (Priority 2). As mentioned, drop me a line when you're ready to start and you'll receive a beta-package. HUI (Encoders/Buttons/LCD) will not change. You need: 1 Core 1 LCD (2x16) 1 Bankstick* 1 DIN** 4 Encoders** 4 Buttons** * optional, but quite useful; up to 8 supported; 1 BS provides 2 banks with 127 programs each = 256 PRG per Bankstick ** theoretically optional, can be set it up via NRPN messages; I have a Mac OS X program that can remote control the box, but no such option for Windows PCs. So I definitely recommend this small input setup :) Cheers, Michael

I don't know protools, but there is no SHIFT-message in MIDI. And "shifted" knobs are normally HUI (Human User Interface) Features, that means it makes no difference if there are two functions on an Encoder with button-feature or two Encoders, cause in both cases two different Controlls will be sent by midi. For a box you're programming by yourself, the last one (two Encoders) is a lot easier to code anyway. If the second Encoder needs additional ON/OFF messages before/after, you might easily implement that. I see no problem here. And turning two knobs at once shouldn't be no traffic problem either; Think about a Midi Song providing data on 16 channels... Best regards, Michael

all right, you're definitely confusing me today ...no... just kidding, you explained this perfectly clear! well, I think this would be a perfect case for an __asm / __endasm; statement, don't you think? I'm not exactly sure, but I cannot remeber having seen something about a carry bit in C. When you shift a bit, it's gone. Though IIRC, there are some libraries that contain similar functions; but as these are not available in our case, it'll be best to do this in __asm. Cheers ;D Michael

WTF is RRNCF and RLNCF? I know I should RTFM and yes: bitfields in SDCC are limited to 8 bits. Unfortunately. Unions and structs can be larger though, so you could theoretically add two or more bitfields to a struct. Haven't done this, though

woooooooooosh! (that was my head exploding). But besides I have not really understood what's going on: The SDCC manual just refers to the mentioned --banksel=nn option. Some options can be overriden by certain #define options in code. I don't think the banksel option is available (at least it's not mentioned in the SDCC manual). Or you request a feature for implementation of a #define option. If it's fixed so fast like last time, you might be a lucky one :) cheers, Michael (are you going to revolutionise SDCC now ;D )