audiocommander
-
Posts
1,358 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by audiocommander
-
-
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,
Is there a diagram for the LPC17 based circuit?
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,
Question 1
Do the beam numbers map beam 1->AIN0, beam 2->AIN1 ... beam 4->AIN3 ?
I have looked through the code, but it is not clear to me.
Question 2
What's your intention with how the beams work? Should the top two beams converge above, below or at the same level of the lower sensors?
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:
Investigate additonal options for routing the controller to send cc or NRPN signals out to a synth
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,
The LCD shows...
B -SPAN
O^E^(and a cursor rectangle)
...after the initial MIOS welcome screen and credits. I've shown ^ (caret) signs although on the display they are more assymetric than that. I suspect that the SPAN is the default harmony mode set and B indicates international.
...
I'm pretty sure that the LCD message is not right
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.
No sounds coming out yet when I wave my hand in the sensor matrix
...
Should I be using the .syx file called "release" for the core?
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."
No response to MIDI notes sent from MIOS studio's keyboard (although my sound card definitely shows MIDI activity)
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
-
Incidentally, ac,
could you possibly confirm that my observations about pitchbend and other parameter tweaks only applying to the next triggered note represent the expected behaviour?
a|x
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
-
But I can still upload the SpeakJet application to the Core PIC using MIOS Studio, presumably..?
I'm happy tweaking some constants etc. in the C code, if I know where to look (and assuming it is written in C, of course).
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
-
Hi toneburst,
He reckons there's a more recent version of the firmware that was produced to fix this issue, but I can't seem to find it.
Not sure if you're (or he is) referring to the PIC Burner's firmware or the firmware of the IIC-SpeakJet-Module "MBHP_IIC_Speakjet":
I have written an inofficial update for the latter, but I only fixed a timer that might not work correct on startup in certain conditions (dunno if this was an improvement, but it fixed the problem I had). On the other hand I'm pretty sure it won't help solving problems that occur during burning the firmware.
This update is included in the SpeakJet MIOS Application package v0.2:
Overview: doku.php?id=midibox_speakjet#speakjet_application_software
and (direct Link) : doku.php?id=speakjet_application_software_v_0.2
(Most of the documentation of v0.1 is still valid)
Please note that v0.2 (MIOS Application, not the IIC-SJ-firmware) will not work with Rio's k64 keyboard extension, which has an adapted MIOS Application to make it fully compatible with k64. Also note, that the v0.2 MIOS Application update was configured for the HandTracker module. So you'll probably have to tweak some settings in the projects config header file to adapt it for your actual interface hardware.
Hope this helps,
Best
ac
-
Hi Chris,
well, I wouldn't call it dead, but it's not extremely alive either :whistle:
There are a couple of threads in this forum, where I talked about my experiences with the Sharp Sensors (e.g. ...you can also use the search).
Did you find that the sensors are slow and noisy?
Yes they are extremely noisy (that's why there is a quite dedicated part of the software trying to smooth the signals.
Though I don't find them necessarily slow. I guess that is most likely due to the Arduino which I have the impression is much more unsuited to realtime musical applications than MB.
Also, have you considered using the longer-range sensors for larger gestures?No, as I was interested in building a gesture area for one hand. To prevent an overlapping of signals, the software uses a MIN/MAX range setting and interpolates in between to allow a relatively large range (0-127).
There are some problems with the SHARP sensors though:
- Very pointy beam measurement (complicated to measure something with a broader or wider area)
- Non-Linear (IIRC this may be linearized in software, but that reduces the resolution, so I'm ok with that)
- Inverted signal shortly before the diodes
- If pointed at each other or to an other IR emitting source can be problematic
- Don't work through UV Glass or if the glass/plastic works like a mirror
Basicly, the HandTracker in ACSpeakJet is more or less a preconfigured ACSensorizer Software that takes the sensor crossing setup (Sensorverschränkung) into account and calculates the opening of a hand in conjunction with a vowel table. Something like this (just to visualize the basic concept)
BEAM1 BEAM2 \ + + / \ / \ / \/ \/ /\ /\ / \ / \ / + + \ BEAM3 BEAM4Of course you might take longer ranged sensors, but then you should think about how to adapt the interface as well.
Hope that helps a bit
Best,
Michael
- Very pointy beam measurement (complicated to measure something with a broader or wider area)
-
Hi Pbard1,
I recently built an AC Sensorizer according to your design and am having a problem with it. All my hardware is vector board' date=' point-to-point, construction. 1 Bank stick. I'm using Bournes push-button detented encoders. All encoders and buttons work in virtual 64e mode. But all I get is PANIC! operation of 1st push button, bank load and save with 2nd and 3rd buttons. I noted that you had helped another midiboxer with a similar issue. Any help would be greatly appreciated. I haven't set up a fully functioning software/firmware compiling environment yet, but I suspect that I will probably have to recompile some code! I've built a midibox-based eDrum machine several years ago, and when I saw your design, I got caught up in the "hobby" again. Thank you (in advance) for any help.[/quote']You should look into two things:
1. DIN Connections
http://www.midibox.org/dokuwiki/doku.php?id=acsensorizer_04#step-by-step_building_instructions
...see point 9 DIN Connections and check your DIN Setup.
As you get a Signal (PANIC), I think it is most likely your wired setup is not right.
Sorry, I don't own a MB64e, so it is quite likely the encoder setup on the DIN is different. However, you can edit the Encoder Settings, so you might not need to resolder your DIN-Board. But that probably requires a little bit of testing, tweaking and fiddling...
2. If you are absolutely sure you connected the DIN right, go and check ACSensorizerDefines.h and tweak around the Encoder settings, esp.
- SENSORIZER_MODEL_ID
- SENSORIZER_INTERFACE
- SRIO
- ENCODERS
- DIN
/* * ACSensorizerDefines.h * ACSensorizer * * Created by audiocommander on 14.12.06. * Copyright 2006 Michael Markert, http://www.audiocommander.de * * ** Description ** * This file contains changeable parameters for recompilation * with different setup modes and adapted settings */ /* * Released under GNU General Public License * http://www.gnu.org/licenses/gpl.html * * This program is free software; you can redistribute it and/or modify it under the terms * of the GNU General Public License as published by the Free Software Foundation * * YOU ARE ALLOWED TO COPY AND CHANGE * BUT YOU MUST RELEASE THE SOURCE TOO (UNDER GNU GPL) IF YOU RELEASE YOUR PRODUCT * YOU ARE NOT ALLOWED TO USE IT WITHIN PROPRIETARY CLOSED-SOURCE PROJECTS */ #ifndef _ACSENSORIZER_DEFINES_H #define _ACSENSORIZER_DEFINES_H #include "ACMidiDefines.h" // ***** BASIC SETUP ***** #define SENSORIZER_MODEL_ID_DEFAULT 0x0 // default configuration (DOUT:1, DIN:0, ENC_TYPE2) #define SENSORIZER_MODEL_ID_ONE 0x1 // first, grey model (DOUT:0, DIN:Xtended with hardware bug, ENC_TYPE1) #define SENSORIZER_MODEL_ID_TWO 0x2 // second, black model (DOUT:1, DIN:default, ENC_TYPE2) // select model ID (dependent settings for DIN, DOUT, ENC_TYPES) #define SENSORIZER_MODEL_ID SENSORIZER_MODEL_ID_ONE // enable modules // the project compiles to a much smaller size if you set unneeded interface options to 0 #define SENSORIZER_INTERFACE_LCD 1 // if LCD conncected #define SENSORIZER_INTERFACE_HUI 1 // if HUI connected (DIN/ENC) #define SENSORIZER_INTERFACE_NRPN 1 // if NRPN-control (via MIDI) enabled #define SENSORIZER_INTERFACE_BS 1 // if Bankstick(s) attached & enabled #define SENSORIZER_INTERFACE_SYNC 1 // if Syncronizer (Clock forwarding & bar counter) enabled #define SENSORIZER_INTERFACE_HARM 1 // if Harmonizer enabled #if SENSORIZER_MODEL_ID == SENSORIZER_MODEL_ID_ONE #define SENSORIZER_INTERFACE_DIN 1 // if EXTRA(!) DIN pins enabled (see DIN, usually pins 16-31, just down signal) #define SENSORIZER_INTERFACE_DOUT 0 // if DOUT module connected (sensors 1..8 => DOUT SR1 1..8) #elif SENSORIZER_MODEL_ID == SENSORIZER_MODEL_ID_TWO #define SENSORIZER_INTERFACE_DIN 0 // if EXTRA(!) DIN pins enabled (see DIN, usually pins 16-31, just down signal) #define SENSORIZER_INTERFACE_DOUT 1 // if DOUT module connected (sensors 1..8 => DOUT SR1 1..8) #else #define SENSORIZER_INTERFACE_DIN 0 // if EXTRA(!) DIN pins enabled (see DIN, usually pins 16-31, just down signal) #define SENSORIZER_INTERFACE_DOUT 1 // if DOUT module connected (sensors 1..8 => DOUT SR1 1..8) #endif // ***** MIDI SETUP ***** #define MIDI_GLOBAL_CH 15 // application wide Midi-Channel: 0-15 #define MIDI_MERGER_MODE MIOS_MIDI_MERGER_DISABLED // if MIDI-IN should be forwarded // harmonizer #define MIDI_HARMONIZE_NOTES 1 // if incoming notes should be forwarded (harmonized) #define SENSORIZED_NOTE_VELOCITY 100 // note velocity for sensorized NOTE_ONs (= CC#0) // syncronizer #ifdef SENSORIZER_INTERFACE_SYNC #define FORWARD_CLOCK 0 // if clock should be forwarded (regardless of MIDI_MERGER_MODE) #define SEND_CONTINUE_EACH_BAR 0 // CONTINUE is sent each first bar #endif // ***** MIDI ASSIGNMENTS ***** #define MIDI_CC_HARMONIZER_LISTEN 37 // 64-127: listen for next note-on, 0-64: exit listen-mode #define SENSORIZER_PEDAL_CC MIDI_CC_PEDAL // select which CC should be sent on pedal down/release #define BROADCAST_PRG_CH 1 // sends PRG_CH on GLOBAL CHANNEL with current bank/patch on load/store (default: 1) // ***** LCD ***** #define SENSORIZER_LCD_TYPE 216 // currently only supported: 216 (=> 2x16) // ***** AIN ***** #define AIN_MUXED 1 // 32 AINs via AIN-module #define AIN_UNMUXED 0 // 8 AINs via J5, default setting #define AIN_MUX AIN_UNMUXED #define AIN_NUM 8 // number of Analog Inputs, default: 8 #define AIN_DEADBAND 7 // 7 for 7-bit values, default: 7 // ***** SRIO ***** #define SRIO_NUM 4 // number of ShiftRegisters: 1..16 (128 DI/O max), default: 4 for 1 DIN-module #define SRIO_DEBOUNCE 0 // 0 = hiQuality buttons, 1 = low quality buttons, default: 0 #define SRIO_UPDATE_FRQ 1 // 1 ms for Rotary Encoders, default: 1 // ***** ENCODERS ***** #define ENC_NUM 4 // number of Encoders #if SENSORIZER_MODEL_ID == SENSORIZER_MODEL_ID_ONE #define ENC_TYPES 1 // mixed speed:1 (for model_one <grey>) #else #define ENC_TYPES 2 // slow:2 <default:2 for Voti.nl Encoders & SMASH's DIN> #endif // Encoder numbers as defined in mios_wrapper/mios_tables.inc #define ENC_PARAM_A 0 // enc number for Param A #define ENC_PARAM_B 1 // enc number for Param B #define ENC_SENSOR_SELECT 2 // enc number for sensor selection wheel #define ENC_MENU_SELECT 3 // enc number for menu switching wheel #define DIN_ENC_PARAM_A 2 // ENC0 PushButton // not needed #define DIN_ENC_PARAM_B 6 // ENC1 PushButton // not needed #define DIN_ENC_SENSOR_SELECT 10 // not needed #define DIN_ENC_MENU_SELECT 14 // not needed // ***** DIN ***** #define DIN_PEDAL 3 // DIN-pin of connected Foot-Pedal #define DIN_PEDAL_SECOND 2 // alternative pin-out (e.g. front _and_ rear) #define DIN_PANIC 7 // sends PANIC! (all notes off) #define DIN_LOAD 11 // loads current patch #define DIN_STORE 15 // stores current settings to current patch #define DIN_EXT_MIN 16 // Extra DIN pins, send out PIN - DIN_EXT_MIN on pressed (no signal on release) #define DIN_EXT_MAX 31 // - " - #define DIN_EXT_CC 14 // CC for extra DIN pins, see above #endif /* _ACSENSORIZER_DEFINES_H */
regards,
Michael
- SENSORIZER_MODEL_ID
-
Hi Julien,
great to hear you like the sensorizer :-)
i got Sharp GP2Y0A21YK ( http://www.sparkfun.com/commerce/product_info.php?products_id=242) but its behaviour is erratic
i attached it under the frontpanel with 2 holes of 4,5mm for the LEDs (to pass the beam) . Is it good ??
Yeah, I'm using some of those with different distances. Thus, it's the main reason, that I created the nice calibration methods. There are two calibration modes, one is min where you should trigger the minimal amount and then set the maximum value. With auto-calibration, ACSensorizer should do the rest for you (I think it might be good to have a pedal attached for that, as it's much easier to press the pedal shortly if you have the right range. I think I wrote a quick setup instruction in the wiki IIRC.
After calibration, the sensors work fantastic and quite stable. Of course (as autocalibration is so easy) you might also use it creatively: for example, you can configure the sensor to work only on one octave. Of course the calibration is saved per patch and not uniquely.
When working with those IR-based distance sensors, you just have to notice the short inverted range that's around 2 to 4 cm in front of the sensor (depends on the model). I also found that the signal quality is varying if there is something reflective in front of the sensor (glass, plexi). Also, some sort of transparent materials might be UV-protected; those will eat (or reflect) the IR-Beams totally.
And btw: it's not worth to take them apart, they won't get better without their custom lenses ;-)
also see: http://www.audiocommander.de/blog/?p=71 (scroll down a bit)
...ah, and make sure, you never (ever!) short-circuit them. I immediately destroyed two while I had them connected wrong for just one second. After that I made sure I used male connectors that accepted only a certain orientation of the female connector. If they're dead, they just transmit glibberish.
I also found that some larger pressure-pads (pressure resistors) work really well, as they provide quite fine control (depends on the type you have though).
cheers
:-)
-
Hi Julien,
that's great to hear... and great that it works, because I have to admit I would have been a bit clueless, as I haven't been much midiboxing lately (unfortunately)
Cheers,
Michael
-
strat-1,
I'm sorry, but it's really hard to say something without knowing the details I asked for (esp. the headers I asked for in my previous posting). I also must admit, that I'm having slight problems understanding you.
So, to sum it up, please answer these questions, so that I can help you:
- what firmware do you have on the 16f88?
- what version of the kII application are you using?
- do you have the AIN enabled in the kII application?
- please post the headers (DEFINE sections) of "main.h" and "IIC_SpeakJet.h"
- what happens if you power the 16f88 without any other module connected? Is the woawoawoa occurring there as well?
Regards,
ac
-
But the speakjet is dead, it says ready on start, and after enters in a weird cycle of woawoawoa.
The 16f88 pic is well programmed, and i tryed every variant of code, nothing works.
I've checked, every month the paths, and wires, and everything it's ok.
If i pull out the 16f88, and shorten the pins for test on speakjet, the test sound it's ok.
Hi,
- what kind of woawoawoa is it? Does it stop, does it continue indefinitely?
is it like this: SpeakJet_Demo_Ready.mp3 ?
if it's like that, it's the test-sequence: in this case the chip is not damaged. It is most likely a sync error in the 16f88 firmware:
- what firmware do you have on the 16f88?
I have released an adapted version for the 16f88, as I had problems with the handshake sync - as soon as I added a short while initializing (in the PIC16f88 firmware) everything worked fine. It should be included in the kII v02 release
...if it's not the test-sequence:
- what version of the kII application are you using?
- do you have the AIN enabled in the kII application?
- could you post the headers (DEFINE sections) of "main.h" and "IIC_SpeakJet.h" ?
- could it be that it's actually working, but some signals are coming in?
- Have you grounded the AINS?
Another thing:
k64 Keyboard Modul → from Rio. Note that an adapted version of the k2 application based on v0.1 is required. The k64 has some additional synth functions, the original k2 app does not provide atm. Future k2-updates may or may not be compatible with this mod.It's a bit silly that the keyboard module is only compatible with a branched kII v01 application mod, but I had severe buffer problems with my sensor-based application with all the synth processing code enabled. Therefore I decided to concentrate on speech for kII v02.
( I feel mainly responsible towards the kII v02 maintenance. I dunno though if Rio's still around here to give support for his keyboard based project )
In other words:
You should only use the keyboard files that incude the kII v01 application mod -
or you could check if it's working with kII v02 (but in this case I guess the keyboard module does not work)
Best,
Michael
-
Hi protofuse,
1st question: can I mix asm and C naturally? I'm not sure. if yes, how I could put that in my code?
you can use plain asm code within your C code (though you cannot add C code to an asm-based project) :
http://www.midibox.org/dokuwiki/doku.php?id=how_to_mix_c_and_asm
2nd question: how should I code that? I mean, should I use a particular value of a midi note on byte (velocity=xx) to make the led blinking?
the most useful tip in the thread you mentioned came from mess:
if you want the timer to do this
*first step is to initialise the timer, call MIOS_TIMER_Init
(see http://www.ucapps.de/mios_fun.html for more info on how to use this function)
*next put your blink code in USER_Timer
do you have experience with assembler coding?
otherwise it would be easier to do this in C
refer to the MIOS C function reference to learn how to switch your pins on and off. It should be fairly simple :-)
best,
Michael
-
Hi Flo,
thanks for your reports.
This problem has been already reported here:
Fatal error: Call to a member function getUserData() on a non-object in /home/midibox/public_html/dokuwiki/inc/common.php on line 1287I hope it'll go away when the DokuWiki is upgraded...
Best,
Michael
-
good to hear :-)
...yay, I finally managed to break the svn spell and commited the change :D
Cheers,
Michael
ACSensorizer Questions
in MIDIbox User Projects
Posted
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