audiocommander

Hi there, hmm, that sounds a bit strange. Saving presets should just work. You can save anywhere, you don't have to select this particular menu. BNK is to select the Bank, PRG is to select the current Program. So, select a Bank/Program and press (the red) WRITE button. Then you can (re-)load this Program anytime. If you didn't save previously (or if there's some other data), it just loads and interprets that other data (probably nonsense). However, if your DIN wiring is still messed up and the LOAD/WRITE buttons aren't working properly, that would also explain why saving doesn't work. The display should also show LOADING or WRITING... (see LCD screenshot overview in the wiki). If this doesn't show, your WRITE-Button isn't working properly. Hope this helps, Michael

Well, there can go a lot of things terribly wrong. To rule out wrong wiring, you could do a general test by removing the encoders and hooking the device up via MIDI. ACSensorizer has a MIDI control API: http://www.midibox.org/dokuwiki/doku.php?id=acsensorizer_04#midi_implementation_charts see NRPN Controls and "Examples: Turning the Menu Wheel (virtually)" I've seen encoders that have different pin configurations than the ones I used here (at 9.) http://www.midibox.org/dokuwiki/doku.php?id=acsensorizer_04#step-by-step_building_instructions Best, Michael

Hi Pawel, cheers and nice to hear you like it. First of all, I have no experience how to compile it with the latest setup. I haven't updated up by MIOS compiler environment for years. But looking at your makefile output, there's clearly something missing with your path, missing in your makefile or indeed simply missing MIOS files in the directory (it says: No such file or directory). So, the error at this point has nothing to do with the ACSensorizer project. Second: please look back a couple of pages. There are at least two different encoder types around and you have to play around a bit with the different ENC_TYPES settings in the ACSensorizerDefines.h file. However, this step requires then a new build. Best, Michael ps: I will be away for the next weeks and return in April, just so you wonder if I don't reply at once.

cheers sneakthief! Thanks for helping out. I was offline a couple of days :sweat: @Elektruck nice to hear you got it working! Hope you'll have fun with it. Best, Michael

Hi Analog Monster, no, there isn't This project has been created 2007, so there's only a PIC based core module: http://www.ucapps.de/mbhp_core.html :-) Though I doubt that anything faster would do any good, as the SpeakJet is quite old and slow as well. cheers, Michael

YAY! (^_^) Congratulations! This is looking really nice, and I like your performance! Cheers, auco

Hi Chris, The beams are not supposed to exacty face each other, that's why I pointed them to different directions (otherwise the bottom distance sensor might receive the beam from the top sender). For all other questions, I suppose you might have overlooked ACHandTracker.h? /* * ACHandTracker.h (...) * This sensor matrix fetches the readings of 4 GP2D-Sharp GP2D120X distance sensors * to calculate additional vars. The matrix is set up by 2 top and 2 bottom sensors * If you put your hand in this space to simulate a hand-talking puppet following * infos are accessible * TL top left sensor 0 value 0..20 cm * TR top right sensor 1 value 0..20 cm * BL bottom left sensor 2 value 0..20 cm * BR bottom right sensor 3 value 0..20 cm * FINGER position of fingers (height top) 0..20 cm * THUMB position of thumb (height bottom) 0..20 cm * OPEN opening distance, space between fingers & thumb 0..14 cm * HEIGHT heigt of whole hand 15..95 Hz * ROLL angle of hand, roll left (0..1) or right (3..4), default 2 0..5 (2) * //BEND not yet available --- (0..15, default 5) 0..15 (5) * * If a hand-opening is detected, phonemes are triggered based on the phonetic topic * tables of the IIC_SpeakJet classes. * * To make it less abstract: * A Cocoa (Objective-C) demonstration program for Mac OS X (maybe it works with GNU-Step * on Linux too, who know ;) This program emulates the sensors and calculates the virtual * open beam. All number-chrunching is visualized there. Frankly, I think the gesture * implementation so far is quite easy to grasp if you see what's going on at this demo. * / (...) // do not change this: #define AIN_MUXED 1 // 32 AINs via AIN-module #define AIN_UNMUXED 0 // 8 AINs via J5, default setting // ...instead select here the MUX-Type: #define AIN_MUX AIN_UNMUXED #define AIN_NUM 4 // number of Analog Inputs, default: 4 #define SENSOR_NUM AIN_NUM (...) // sensor matrix hardware #define HT_TL 0 // AIN pin num of top left sensor #define HT_TR 1 // AIN pin num of top right sensor #define HT_BL 2 // AIN pin num of bottom left sensor #define HT_BR 3 // AIN pin num of bottom right sensor // sensor config // use 16bit division math; best linearized results #define USE_COMPLEX_LINEARIZING 1 // if disabled, uses lookup table (not recommended, only GP2D120X supported!) #define GP2D120X 0x30 // 4..30cm Sharp Distance Sensor #define GP2D12J0 0x80 // 10..80cm Sharp Distance Sensor #define HT_SENSORTYPE GP2D120X // which sensor type is used // note that a sensorType other than GP2D120X has never been tested; // it's probably better to leave GP2D120X even when working with a GP2D12J0, // because all calculations are optimized for 0..26 cm; as the voltage is relative, this should be no problem... (...) #define SENSOR_SLOWDOWN 4 // every nth signal will be processed (per sensor), only if not quantized // gesture detection #define GESTURE_SLOWDOWN 4 // every nth update will be processed (unrelevant if SYNC_ENABLED!) #define TRACKER_THRESHOLD 10 // every nth update will be requested (unrelevant if SYNC_ENABLED!) #define SMEAR_VOWEL 126 // used for enunciate, see SJ_MidiDefines for SJCH_xx typedefs // midi related #define SENSORIZED_NOTE_VELOCITY 0 // note velocity for sensorized NOTE_ONs; 0 for lastPhoneme (default: 100) #define HANDTRACKER_CC_OUTPUT 1 // if tracked values should be sent by midi #define HANDTRACKER_CC_OUTPUT_VERBOSE 0 // if additional values like AIN values should be sent by midi/CC (...) I guess this should answer all your questions :ahappy: If you're interested how I mounted the sensors, you should check out this docu, esp. the second vido with the wooden test-rig and the detailed photos of the sensor mountings in my second machine (clear case) : http://www.audiocommander.de/blog/?p=71 Cheers, ac

Heya, nice to hear it's working :thumbsup: IIRC there's a MIDI Merger setting somewhere that activates MIDI forwarding to the output. Best, ac

sry, I'm on the Mac here and am not at all up to date with all the latest developments. But I'm pretty positive that all the registers in ACSyncronizer are fine :sweat: (it's written in C, so the error probably comes in after the ASM is generated). Regards, M.

Hi Chris, v0.1 uses a 16x2 LCD and in v0.2 I'm using a 8x2 LCD. As 8x2 LCDs are quite rare, I suspect, you are showing the 8x2 output on a 16x2. Which works, but it might look strange. The O means "Oscillator", the E "Envelope", B is the base note and SPAN is the 4-char code for the current scale (SPANISH) ...but this is all in the docs: http://www.midibox.org/dokuwiki/doku.php?id=speakjet_application_software_v_0.1#lcd-values Also, you can take a look in the main.c file to see the LCD output function: DISPLAY_Init() and DISPLAY_Tick(). These are really clean to read and you'll see the various Buildmodes (that means you can change the settings for the LCD you have in main.h: KII_LCD_TYPE... but I think I mentioned this a couple of times). Note that I have two devices and one doesn't use any LCD at all, that why it was no priority for me to show informations. But you can change this quite easily. I compiled this nearly four years ago, so I really can't remember every setting in the various precompiled syx files for the various device configurations I have plus the default userland settings that are around. I guess you are referring to the 0.2 "release"; this is most likely built with the BUILDMODE_DEFAULT setting. If you take a look in main.h, you'll find all the settings: #define KII_AIN_ENABLED 0 // if AIN (sensorMatrix) enabled #define KII_LCD_ENABLED 1 // if LCD is attached #define KII_SYNC_ENABLED 1 // if SYNC features (MASTER/SLAVE) are enabled #define KII_WELCOME_ENABLED 1 // enunciates welcome message on startup #define KIII_MODE 0 // for use with Mac OS kIII software only. #define MIDI_MERGER_MODE MIOS_MIDI_MERGER_DISABLED // if MIDI-IN should be forwarded #define KII_LCD_TYPE 28 // currently supported: 216 & 28 <default> #define ACSYNC_GARBAGE_SERVICE 0 // if a reset should be done each ACSYNC_GARBAGE_SERVICE_CTR #define ACSYNC_GARBAGE_SERVICE_CTR 23 // each x bars a reset is done, default: 23 (1..23) #define ACSYNC_GARBAGE_SERVICE_HARDRESET 0 // if a hard- or soft-reset of the SJ is done, default: 1 #define SCALE_DEFAULT 20 // 0 for not harmonized, default: 20 (spanish) #define BASE_DEFAULT MIDI_NOTE_H // MIDI_NOTE_x, default: MIDI_NOTE_H And there's also your answer, why nothing is happening if you waive your hands: the KII_AIN_ENABLED is set to 0 by default. Again (as mentioned "you can change these settings as well, or add a new buildmode depending on the needs of your device (that was the idea behind this mode, so that it can be easily built for one device by changing one #define only." I can't say much about this as it's a very vague statement. Possible failures could be usage (right MIDI-Channel, volume, jaw/tonge-setting?), hardware (soldering, connections?), wiring or software (Midi I/O config, driver). btw: it's normal for the regulator to get quite warm. Because you don't have "funny burning smells" :D , I guess it's okay. But if it gets too hot, there might be a severe problem (usually related to wiring). Regards, Michael

Hi Chrisbob, there are a couple of threads on this forum, where we discussed the implementation of the Sharp IR sensors in great detail. As you already found out, they don't deliver the full 0-5V range, so a scaling is required. Personally I found software scaling much easier than hardware scaling (requiring an amplification circuit and a higher voltage) and thus implemented a good software scaling that works well. Moreover, the scaling can be calibrated which is a lot nicer than hardware scaling. Please use the search function to find the relevant threads (good keywords are: IR, distance, sensor, sharp, d-beam, ...) Best, Michael

IIRC yes, that is because of the way the SpeakJet works - you can send some control messages to it and then it'll react. I don't think it was possible to play a vowel and then change the pitch of that playing vowel. In contrast to changing an OSC that has been switched on, so there are much more control possibilities. Allophones are kind of pre-calculated OSC-Settings with specific curves, so (again IIRC) you can't alter them that much in realtime. However, you can alter almost anything if you know it in advance. But I guess the SJ has been produced for enunciation with a dictionary (there's a companion chip with an english dictionary btw), thus all parameters would be known in advance. And besides, there's just this 64-byte input buffer which is really (really) small and may overflow quite easily, esp. if you send loads of controller values coming from a mechanical slider; just one slide and you'll produce lots of bytes in a very short time. I tried some tricks to work with that application side (but I'm no pro either and just an autodidact, so....) It would probably be good to take a look in the datasheet for a refresher of the theoretic background of the chip: http://www.magnevation.com/pdfs/speakjetusermanual.pdf To check out the "raw" capabilities of the SpeakJet chip and store phrases in the EEPROM, I found the Phrase-a-lator software best. Unfortunately it only works from Windows and you need the chip hooked up via RS232 (but there's also a user manual that helps to see the possibilities) http://www.magnevation.com/software.htm I think it may be challenging and tough to develop a custom speech/allophone software. There are some resources to check, like: - Flite: http://www.speech.cs.cmu.edu/flite/ (small C speech engine) - Language Construction Kit: http://www.zompist.com/kit.html (theoretical background on phonological issues when creating a language - Festival (Free Speech Generation) & FestVox - Cairo (Java) http://www.speechforge.org/projects/cairo/ ...but I found that high quality sound generators are all closed source and good algorithms are valuable and thus hard to find (if not even unavailable) --- About the harmonizer: IIRC you should be able to change it via MIDI (so no need to recompile). It should use those new values (can be looked up in "ACMidiProtocol.h") : #define MIDI_CC_HARMONY_BASE 80 // 0x50, 0-11, see MIDI_NOTE_x #define MIDI_CC_HARMONY_SCALE 81 // 0x51, 0:none, 1-127:scaleNum so you could try sending CC81 with a value of 0, then there's no scale (Global Channel should be 0) (if it doesn't work you can test CC38 from v0.1, but I'm pretty sure it's now 81 as I overworked that to play along well with all my harmonizer based projects). Best, Michael

indeed, it's just a very tiny (and old!) chip, so one shouldn't expect too much, but I really like your demo! About the MidiChannels: right, I experimented a bit with this version (but it's nearly four years now, so I don't remember exactly what I changed, but your description sounds like it's all fine). I guess you've already seen it, but you can find the (outdated v0.1) Midi chart here: http://www.midibox.org/dokuwiki/speakjet_application_software_v_0.1#midi-implementation-chart. You can also take a look in the IIC_SpeakJetMidiDefines.h file and adapt these to your needs: // ********* SPEAKJET MIDI ASSIGNMENTS * // // MIDI ASSIGNMENTS // optimized for KORG microKONTROL // // just assign the ControlChange or Channel Numbers to the functions // eg: CC 107 on CH 1 controls the SPEED of the SpeakJet Allophones (SJCC_SPEED) // eg: Notes on CH 2 trigger allophones (all phonemes) (SJCH_ALLOPHONES) // // some midi-controls are hardcoded (can't be assigned here) // channel control messages like PITCH-WHEEL, AFTERTOUCH or PANIC and // system realtime messages like START/STOP/CONTINUE // ********** CHANNELS ********** // channel assignments for NOTE_ONs 0x90 and NOTE_OFFs 0x80 functions // MIDI CHANNELS for NOTE_ONs #define SJCH_SOUNDCODES 1 // MSA Soundcodes (Allophones + FX) default 1 #define SJCH_ALLOPHONES 2 // MSA Soundcodes (Allophones) default 2 #define SJCH_FX 3 // MSA Soundcodes (FX) default 3 #define SJCH_PITCH 4 // MSA Pitch (Note2Freq) only! No sound output! default 4 #define SJCH_VOWELS_DIPHTONGS 5 // MSA Pitched Vowels incl. Diphtongs default 5 #define SJCH_CONSONANTS 6 // MSA Pitched Consonants (depending on jaw & tongue)* default 6 #define SJCH_VOWELS_CONSONANTS 7 // MSA Pitched Vowels & Consonants (mixed) default 7 #define SJCH_CONSONANTS_OPEN 8 // MSA Pitched Consonants produced by mouth opening default 8 #define SJCH_CONSONANTS_CLOSE 9 // MSA Pitched Consonants produced by mouth closing default 9 #define SJCH_PERCUSSIVE 10 // MSA Soundcodes (Percussive Consonants) default 10 #define SJCH_OSC1 11 // OSC 1 (Note2Freq, monophon) default 11 #define SJCH_OSC2 12 // OSC 2 (Note2Freq, monophon) default 12 #define SJCH_OSC3 13 // OSC 3 (Note2Freq, monophon) default 13 #define SJCH_OSC4 14 // OSC 4 (Note2Freq, monophon) default 14 #define SJCH_OSC5 15 // OSC 5 (Note2Freq, monophon) default 15 #define SJCH_OSC_SYN 16 // OSCs 1 to 5 (Note2Freq, harmonic polymode) default 16 And don't forget about the main.h settings, the most important here is the BUILDMODE: // general defines #define FALSE 0 #define TRUE 1 #define BUILDMODE_DEFAULT 0 #define BUILDMODE_KTWO_BLACK 1 #define BUILDMODE_KTWO_ACRYL 2 #define BUILDMODE_KTWO_CROSS 3 #define BUILDMODE_KTWO_TESTPCB 4 // select buildmode (predefined settings) #define BUILDMODE BUILDMODE_KTWO_CROSS //BUILDMODE_DEFAULT so for example, with buildmode "BUILDMODE_DEFAULT" you get: #if BUILDMODE == BUILDMODE_DEFAULT #define KII_AIN_ENABLED 0 // if AIN (sensorMatrix) enabled #define KII_LCD_ENABLED 1 // if LCD is attached #define KII_SYNC_ENABLED 1 // if SYNC features (MASTER/SLAVE) are enabled #define KII_WELCOME_ENABLED 1 // enunciates welcome message on startup #define KIII_MODE 0 // for use with Mac OS kIII software only. #define MIDI_MERGER_MODE MIOS_MIDI_MERGER_DISABLED // if MIDI-IN should be forwarded #define KII_LCD_TYPE 28 // currently supported: 216 & 28 <default> #define ACSYNC_GARBAGE_SERVICE 0 // if a reset should be done each ACSYNC_GARBAGE_SERVICE_CTR #define ACSYNC_GARBAGE_SERVICE_CTR 23 // each x bars a reset is done, default: 23 (1..23) #define ACSYNC_GARBAGE_SERVICE_HARDRESET 0 // if a hard- or soft-reset of the SJ is done, default: 1 #define SCALE_DEFAULT 20 // 0 for not harmonized, default: 20 (spanish) #define BASE_DEFAULT MIDI_NOTE_H // MIDI_NOTE_x, default: MIDI_NOTE_H #endif /* BUILDMODE_DEFAULT */ of course, you can change these settings as well, or add a new buildmode depending on the needs of your device (that was the idea behind this mode, so that it can be easily built for one device by changing one #define only. ...and I have to admit, I haven't looked at the port, so files and settings might be somewhere else... Cheers, ac

Hm, sorry, I don't know if there are any custom made PCBs out there... don't think so. I did several matrix boards, one of them I painted green (though I don't know why, it was just a fun-thing; probably because there were some old marks on it or something like that). The board used for the machine in the Kinetica Gallery was the manual matrix board though :sorcerer: Cheers, ac

sure, just take a look in main.h. Maybe the default values (BUILDMODE_DEFAULT) are okay for you. I just seen that the AIN Matrix (HandTracker) is disabled by default, so it might even work without tweaking. cheers, ac