audiocommander

I attached an update where I set the main font and the headlines to "sans-serif", so it falls back to the font you chose as "sans-serif" in your browser. I also fixed the <li> spacings in the toc. MidiBox DokuWiki Style AC Edit4.zip MidiBox DokuWiki Style AC Edit4.zip

From what I see in the picture' date=' I guess you mean the fuzzy rendered headlines? I honestly don't know what to do about this, other than [i']<angry redfaced uncontrolled emotional outburst>trashing the f**ing ugly IE</arueo> or <taking a deep breath gaining back self-control />arguing with stryd about the serifs in the capital "I". You see: -> I can't use Verdana or Lucida Grande or any serif-font, because stryd does not like the slab-serifs in the "I" -> I can't take Arial Black, because it obviously renders non-aliased in IE -> so what should I do? I'm running out of options, when I'd like to have a non-serif xtra bold font (a thin one is looking totally shitty!) I know that we're not going to make everybody 100% happy... but it's not really helpful to say "it's ugly" ... so please make your alternative font-suggestion instead; give me a bold sans-serif font (with no serifs on the "i") that is rendered normally in IE.

I see. I thought you mean 1.6, because I couldn't find any LC application at the C-download section (had to search the forum first)... Indeed it's in C and the Makefile is missing (as well as Makefile.spec). You might ask TK for that file; but alpha means it's even before beta; so you must not expect a ready-to-ship-and-able-to-compile-for-everyone-state ... I guess this exactly is the reason why it's not (yet) listed in the download section. However, as you can compile your SDCC skeleton successfully with "Hello World", this indicates that your system is now set up well to build C-based applications. Maybe you should ask in some LC-based thread now? :) best, Michael

:o jeesuz, cimo, I have never checked this, 'cause I thought it would be obvious that you're working on a C-based project – you are trying to edit an ASM-application!!! forget this. you cannot edit an ASM-project in C. Either you have to proceed in ASM (not my cup of tea, sorry, therefor no Xcode help available from me; I did all the ASM hacks I ever did on Windoze) - or take a look at the available downloads in the C section sorry mate. :-\ Michael Edit: but at least you can code in C; as the SDCC-skeleton seems to work ;) Maybe you can code your own LC app in C?

Hey stryd! I was slightly worried yesterday night not seeing you hanging around in the chat room ;D (I'm not so often there, 'cause it's really stressy here these days...) Of course you can make the makefile manually by calling the mkmk.pl in the console / DOSbox / terminal, but as you need to re-generate the Makefile whenever a new class has to be added, I think this is the smarter way. Besides, I discovered it to be very useful to grasp the concept of creating new targets ;) I'm not sure if it's necessary at all to create a new Makefile on Windows (?), but it is needed on the Mac... However, I don't think it's "bad practice" to not set up a new makefile target in C::B ;) Cheers! Michael

I've added a new general overview to the Wiki that explains some fundamental basics about the compile process: http://www.midibox.org/dokuwiki/how_to_use_xcode2_as_ide_on_a_mac#about_targets_and_makefiles In short: I think you're mixing up the makefile generation process with the "normal" building process to generate the .hex/.syx files ;) And it's quite normal, that the building process just happens once, because Xcode won't compile again if no sources have changed. Tell me, if this helped! Best, Michael

wow, this is what I call a nice navigation :-X I dunno, have no part number, but basically it's the same as used on the Core Module, just with 20 MHz instead of 10 MHz: http://www.mouser.com/search/productdetail.aspx?R=XT9S20ANA10Mvirtualkey61300000virtualkey73-XT49S1000-20 http://www.midibox.org/dokuwiki/parts_faq#what_type_of_crystal_should_i_buy Best, Michael

hi cimo, these error messages are nothing to be afraid of, the only difficulty is to find the first error message (at the end)! It sais: so, the script can't change to the subdirectly "$SRCROOT/tools" (where $SRCROOT means the source root directly), therefore it cannot start the mkmk.pl; this is a PERL-script to generate the new makefile. Just make sure this file (mkmk.pl) is inside a folder "tools". This folder is normally included with most downloads; chances are very likely you already have this file on your HD. Best, Michael ps: I don't think it's required, but you may need to set the right permissions to execute mkmk.pl. In this case, open the Terminal and type: [tt]chmod 750 [/tt] add a space and drag the file "mkmk.pl" to the terminal window. Type enter.

hi cimo, [tt]PATH=:</sw/bin:/sw/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin>:/usr/local/bin[/tt] you must not add the "<" and ">" to your path! The ":" separates the paths from each other, you're just adding "/usr/local/bin" to your $PATH this line has to look like this: [tt]PATH=:/sw/bin:/sw/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin[/tt] best, Michael

Hi I am using shielded 25m cables on an AIN, that's working well if I don't cross high voltage cables (400V). I just had once problems with induction signals. As I'm using this with my Sensorizer, a slight drop of voltage is not the point for me. As you're not saying what you want to do exactly (so I don't know if you're trying to add 100 buttons or 4 step mats), I'd just experiment a bit. The thicker the diameter of the cable the longer it can be. But as TK already said, this won't work for the multiplexed connections between the Core and the modules; this should only work for the module and the connected switch/button/whatever. Another option might be to use two MIDIboxes connected to two computers with (W)LAN. I dunno about PCs, but on Mac OS X there is an inbuilt function to exchange MIDI data between computers over LAN. So, by using two Cores and two Mac Minis or iBooks, you could set up a local LAN or WLAN and exchange MIDI over these laptops. Mabe there are also active MIDI cable extenders? I'm sure that more people want to have longer MIDI cables than 10 m. iirc TTL signals will work from 4.5 to 5.5V; there are digital multiplexers and demultiplexers that can encode and decode digital signals (eg. 4-to-10 and 10-to-4). Therefore you could also set up your own matrix; and even if the 5V drop to 4.5, it should still work. I don't know however, if there are any timing issues. Best, Michael

Hi squeal, no prob. welcome to the forum ;-) in guess this should be possible, but IIRC line-in signals are 1.2V max; the AIN would reach it's maximum at 5V. Maybe someone else can say something about possible dangers, dunno about the currents? Although it's not exactly what you're after, this userproject might from lylehaze might have some infos of value to you: http://www.midibox.org/dokuwiki/midiboxmixer Best, Michael

yep :) it's truly unique, but beware though that the sound is of course not high quality (there's a bit noise on the output, but it's okay for me) that's quite easy' date=' you just have to change the defaults for all SJCC_*** in IIC_SpeakJetMidiDefines.h ...maybe in ACMidiProtocol.h too, where harmony changes are defined, but I found that useful to have a standard for inter-device and -application harmony changes; for example: if you should ever build an ACSensorizer, the kII automatically changes it's current harmony (base+scale) if the Sensorizer does and vice versa. /* * IIC_SpeakJetMidiDefines.h * kII * * Created by Michael Markert, audiocommander.de on 26.08.06 * Copyright 2006 Michael Markert, http://www.audiocommander.de * */ /* * 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 _IIC_SPEAKJETMIDIDEFINES_H #define _IIC_SPEAKJETMIDIDEFINES_H // include standard MIDI names // you can then use MIDI_CC_VOLUME instead of 0x7 #include "ACMidiDefines.h" // ********* 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 // the following channel types can also be used, but make sure only 16 channel nums are defined! #define SJCH_VOWELS 255 // MSA Pitched Vowels only (depending on jaw & tongue)* default 0 (n/a) #define SJCH_DIPHTONGS 254 // MSA Pitched Diphtongs only (depending on jaw & tongue)* default 0 (n/a) // ********** CONTROL CHANGES ********** // general #define SJCC_CHANNEL_ASSIGNMENT_TOGGLE 17 // switch to next channel assignment, CH1=>CH12 (channelAssignment, main.h) #define SJCC_CHANNEL_ASSIGNMENT 18 // set channel assignment, 0..127 => 1..16 (channelAssignment, main.h) #define SJCC_PHRASE 9 // pauses: pause 0(0ms) / 1(100ms) / 2(200ms) / 3(700ms) // pause 4(30ms)/ 5(60ms) / 6(90ms) #define SJCC_PAUSE0 255 // 0 ms // inactive! #define SJCC_PAUSE1 22 // 100 ms #define SJCC_PAUSE2 23 // 200 ms #define SJCC_PAUSE3 24 // 700 ms #define SJCC_PAUSE4 254 // 30 ms // inactive! #define SJCC_PAUSE5 21 // 60 ms #define SJCC_PAUSE6 253 // 90 ms // inactive! // modifiers: slow/low/high/fast #define SJCC_NEXT_SLOW 25 // play next phrase ... #define SJCC_NEXT_LOW 26 #define SJCC_NEXT_HIGH 27 #define SJCC_NEXT_FAST 28 // phrases: call phrase #define SJCC_PHRASE0 29 // play internal phrase ... #define SJCC_PHRASE1 30 #define SJCC_PHRASE2 31 #define SJCC_PHRASE3 32 // step phrase record (not activated by default!) #define SJCC_PHRASE_REC_UNDO 33 // delete last recorded command #define SJCC_PHRASE_REC_ABORT 34 // stop recording, delete buffer #define SJCC_PHRASE_REC 35 // start recording #define SJCC_PHRASE_REC_PREVIEW 36 // preview buffer // harmony control (also see ACMidiProtocol.h!) #define SJCC_HARMONY_LISTEN 37 // 64-127: listen for next note-on, 0-64: exit listen-mode #define SJCC_HARMONY_SCALE 38 // 0-SCALE_MAX: set scale, 127: next scale #define SJCC_HARMONY_BASE 39 // set new base note // articulation controls #define SJCC_MOUTH_JAW 40 // jaw position (low/mid/high) #define SJCC_MOUTH_TONGUE 41 // tongue position (front/center/back) #define SJCC_MOUTH_HEIGHT 42 // pitch, note-height (send only! use notes on CH# SJCH_PITCH to receive!) #define SJCC_MOUTH_STRESS 43 // same as bend #define SJCC_MOUTH_SPEED 44 // same as speed #define SJCC_MOUTH_PAUSES 45 // inserts pauses (long/short) #define SJCC_MOUTH_PHONEME 46 // last phoneme (send only! use notes on CH# SJCH_ALLOPHONES to receive!) // OSCx Frequency #define SJCC_OSC1_FREQ 101 #define SJCC_OSC2_FREQ 102 #define SJCC_OSC3_FREQ 103 #define SJCC_OSC4_FREQ 104 #define SJCC_OSC5_FREQ 105 // OSCx Level #define SJCC_OSC1_LVL 111 #define SJCC_OSC2_LVL 112 #define SJCC_OSC3_LVL 113 #define SJCC_OSC4_LVL 114 #define SJCC_OSC5_LVL 115 // OSC controls #define SJCC_OSC_WAVESHAPE 50 // switch to next osc additive synth waveshape #define SJCC_DISTORTION 118 // distortion level (mix) for OSCs 4 & 5 // ENV controls #define SJCC_ENV_OSC_A 53 // ENV on/off for OSCs 1 to 3 #define SJCC_ENV_OSC_B 54 // ENV on/off for OSCs 4 and 5 (half enveloped only) #define SJCC_ENV_OSC_TGL 52 // toggle ENV on/off for OSC groups (00, 01, 10, 11) #define SJCC_ENV_WAVESHAPE 116 // set ENV Waveshape 1:0..31, 2:32..63, 3:64..95, 4:96..127 #define SJCC_ENV_WAVESHAPE_TGL 51 // switch to next envelope waveshape, also see SJCC_ENV_TYPE #define SJCC_ENV_FREQ 106 #define SJCC_SYNTH_ENV 56 // ENV on/off for Additive Synthesis // speech params #define SJCC_SPEED 107 // same as SJCC_MOUTH_SPEED #define SJCC_BEND 117 #define SJCC_MASTER_VOL 108 // Joystick X/Y: Pitch / Env Freq #define SJCC_PITCH MIDI_PITCH #define SJCC_FREQ MIDI_POLY_AFTER // same as bend [/code] maybe I need to add some words about the Channel modes (SJCH_***): the channels at the top of this file are used to play in different modes; eg. when you want to trigger consonants only, you can send notes from CH6. But there is also a channelAssignment; if this is set to a value between 1 and 16, you can change the "default" behavior, eg. if you send notes from CH6 but the ChannelAssignment is set to 3, you trigger FX sounds only. This "mode"-number is also shown in the 1x8 LCD. And you may need to set KII_AIN_ENABLED in main.h to 0 - I will make this the default setting in the next update anyway; I can release this as soon as I'm back. If you have troubles in recompiling the sources, I can also do this for you and send you a .syx file if you submit me your adapted IIC_SeakJetMidiDefines.h. no problem, ultra :) just don't forget that I'm away the next days. I hope that assembling the IIC_Speakjet after this tutorial shouldn't be harder than assembling a Core Module. Just follow the PDF (the different views should help keeping the overview). burning the firmware to the PIC16F shouldn't be big of a problem either. If you have troubles, I'm sure someone will burn the chip for you (I could do this as well). Best, Michael

Hi ultra, if you're just interested in midi-control of the sj, it's indeed ready to be used and quite future-proof. It's very unlikely that the hardware will change; there will just be some more software-features added, if there is enough interest. This is the latest version: ?topic=2870.msg63685#msg63685 date=1176227557 The project was not very active the last months because the current status has been sufficient to me and there has been no one else that built this. So if there is interest, I will surely resume to work on this project. these things are still to be done: - a base-note bug (fixed this in the sensorizer but not yet in the kII, just a matter of time) - software phrase support (not that easy due to possible buffer overflows, critical timing issues; would do that if there is enough interest) - hui input (buttons, encoders...) I have not done this, because the external phrase support and functionality is not thought over. Also, I'm not convinced that a (computer) keyboard is a wise input device, because when it comes to speech, we're not talking about words and chars, we're dealing with phonemes. Introducing typed chars requires a word-to-phoneme dictionary that cannot ever be complete and is restricted to the english language. Moreover (and this is a personal believe), I like the idea of not just imitating the human language, but to take the electronic speech one step further in musical terms. these things won't be done by me, though it would be okay for me to integrate them if they are coded well and easy to take over (namespaces, blackboxed/encapsuled functions): - extra manual envelopes like suggested by rio. In my eyes, these just produce unnecessary extra serial messages, that make it more probable to overflow the 64 byte input buffer. I think it would be smarter to use a better suited chip (like the soundGin) for things like these, it has by far the better synth capabilities. - phrase storage write access to the SJ. this is a critical issue, because if there is some small error in the buffer (-> again my friend the overflow) it might write bad data to the chip and possibly destroy the firmware. Anyway: regarding the low storage space (IIRC just 256 phonemes for all 16 phrases), I guess it's a lot easier to use the provided magnivation PC-program to save some default phrases - and instead add an external phrase manager. this would have the advantage to enable the storage of lots of phrases in a bankstick module. I am using a 1x8 lcd because I think that's sufficient (harmony/channel/envelope/osc-env/beat-quantisation). If you have trouble finding 1x8 lcds, I can implement support for 2x16 of course, too (I got some 1x8 extremely cheap from pollin) please ask if you have more question; though I will be on holidays the next days, so do not wonder if my answers will take a bit longer ;) Cheers, Michael

clearing the background by painting on the display surface with TippEx? ;D

Hi stryd, well, doesn't look that bad like I expected ;D to img1: - the "misc" box should be right-aligned; if you decrease your window width it would be rendered normally (then the left floating box becomes larger). a quick workaround for this would be to add a horizontal <hr> right before the "Misc"-Box, but that would add a fixed vertical space (as to be seen in http://www.midibox.org/dokuwiki ... MBHP <-> MIOS ...dunno if this would be better in this case). Maybe this could be also solved by tweaking the CSS properties for the floating boxes; I'll have to check this... to img2 & 3: - as jimp just said nearly simultaneously, the grey images are a result of transparent PNGs, these are not supported by IE < v7. The only "workaround" for this would be transparent GIFs :-X - for the box position in img2 it's the same as described above Best, Michael ps: Thanks for the kind feedback to jimp & MTE :) Edit: http://www.midibox.org/dokuwiki/projects better now? ;D

bravo !!! :D about your question: I'm quite sure you're using the latest 0.4.5 version; there's been a bug in the previous versions that might explain this. Normally all events below min and above max are ignored. It may be though, that if the factor is not well chosen, there might be a loop within the scaling function (the last menu page -> from...to). If you used the Autocalibrate function, this should normally not happen. Maybe it helps if you describe the "strange behaviour" better. I'm on holiday for about 12 days starting wednesday, so please don't wonder if I'm not answering at once the next days... Best ;) Michael

right; I switched the home page. :D main overworked pages are: http://midibox.org/dokuwiki/ http://midibox.org/dokuwiki/projects http://midibox.org/dokuwiki/mbhp There are still some subpages that need a workover, eg MIOS, the Tools or Basics; but at least it's a beginning... The boxes are indeed a very nice plugin. We have now these colors: (nothing=dark grey), grey, bluedark, blue, bluelight, red, orange, yellow, green I'm usually using 48% width; as Didier said: when the boxes kill the layout, just add a <hr> ("----") below. Best Michael

okay, then maybe we should give the new css styles a try? I'll be here for two more days and then on holiday next week, so we could catch some (constructive) opinions and see what works and what not: (css files attached) :) best, Michael MidiBox DokuWiki Style AC Edit3.zip MidiBox DokuWiki Style AC Edit3.zip

more ideas: The more I look at it, I like the last one (currently just the buttom of the page) best; maybe we should make a real clean entry page; in this example: take all the colorful stuff and put it into a MBHP subpage. dunno about projects... then just five entry-points: - General - Projects (Devices) - Hardware (MBHP) - Software (MIOS & Tools) - Users (Community) best, Michael

thank you :D (and thanks of course to ptitjes and nebula :) ) I'm currently experimenting with images inside the boxes, maybe I need to adapt the CSS once more...

okay, I see now what stryd meant :) iirc this is called a slab-serif and I wouldn't mind that; but took an Arial Black in exchange. I took away the spaces again, but added an overline for the headers; I still think they should be better separated from the content above. I overworked the link colors (& removed the bold). and checked the IE: (of course) stumbled over two bugs: the -hr- is shown in IE (but I guess it should not) and I fear there may be an issue with the list dots ...grrr... the last four are direct comparisons now/update what'ya think? best, Michael MidiBox DokuWiki Style AC Edit2.zip MidiBox DokuWiki Style AC Edit2.zip

hmm, I must admit, I do not understand what stryd is talking about ??? :scratchhead: but I'd like to get some more feedback on the css update (that one with the screenshots above); 'cause I'm going to holidays next week and maybe I could finish that one up. I see your points ptitjes, no prob, could change this - just thought that the links are quite important, but I'm not keen on making them bold by default... I just don't know what you mean with the "space between caption and content"; this looks quite normal to me (but maybe I'm looking at the wrong pic) :) any other opinions? Cheers, Michael

hello mates, I just couldn't stop to digg around in the css; I uploaded some screenshots and attached the modified css. Maybe someone should verify these before installing them on the server; I must admit I haven't checked if some of my modifications would affect the IE ;D I made these changes: - midibox "logo" - headlines (mainly increased the distance to the top. we should have to remove some manual spaces in the wiki -esp. in the "old" (current) homepage-, but I think a bit more space really helps the overview) - switched to Arial as default font; I think it's a bit cleaner this way - overworked li-distances and made the color lighter (I think this is improving the layout a lot!) - added two more blue tones (bluelight and bluedark) for boxes - made the internal links darker and bold - edited the code2 colors (I hope these aren't too radical changes, but I always find red comments better than light grey; helps me reading quickly through sources) Best, Michael MidiBox DokuWiki Style AC Edit1.zip

the boxes are here: http://www.midibox.org/dokuwiki/doku.php?id=start I will download the css and make some additional tweaks (eg, I think the link color is a lot better than before, but a bit too bright)... but it's really gotten a lot better! Thanks Didier! A redirect will be a good thing, because if we're using the sidebar somewhen, we can then easily update old pages to use new namespaces :) Cheers, Michael

I mean "text-align:left" instead of "text-align:justify": left: ------ --------- --- ------ ------- justified (theory): ---------- ---------- ---------- ---------- justified (practically in our wiki): --- -- -- - ---- --- -- -- ----- yeah, I thought this would look a bit less-scaring ;D (I think I took the blue background of the blue box and copied it to the rest of the backgrounds) and for the titles, we should also: - set the font-color to white, - make it bold and maybe also - 120% font-size, so that's it's a real title. Cheers, Michael