audiocommander

Hi Didier, Thanks, mate. That's so cool, that you do this! The link colors seem very plausible to me, looking so forwad to ;D About the box-colors: as I understand, the color you can choose for the boxes (eg by writing "blue"), is simply picking up a css-type called "blue"; maybe we could also add some more? eg. I'd really like a grey one (so color "black", maybe?) and some variations of blue. For the rest, I recommend stronger colors for the title only: blue: #0070ef red: #f12800 green: #84b50d orange: #ff8000 yellow: #ffd100 would be very nice to have, too (for red->orange->yellow) grey: #92aab5 , a cool grey would also be nice to have (for blue->grey->green) if we'd add then for example two more classes named "bluelight" and "bluelighter" (just for example, maybe also "blue2" and "blue3" with decreased saturation, this could give a nice blue box ensemble: 100% Saturation: #0070ef, ~75% Sat: #34a7f1 ~50% Sat: #77c7f2 -> or we could go and instead use colors used in electronics, eg. from a green PCB: green (different greens), gold (yellow with a slight note of green), silver, white (light grey). (the more I think about that last option, the more I'd prefer it :D ) what do you think? Best, Michael ahh, and I got one more wish =) could we disable the block-sentence? with very short lines this is always looking very messy. better to have a nice left-aligend text block than an ugly text block with huge white spaces in between...

hehe... scaring with pastels ;D Agreed, but some decent color variations would be nice to quick sort the items. If you should lay your hands on the CSS, I'd also love to see some typo spacings fixed: esp. for headlines and listings I find it always quite disturbing that the distances below are greater than above, eg: would be a lot better readable if it were like this: ahhh, and one more thing, that scares me: the ugly green/purple link colors

It's very nice working with the boxes, and astonishing how fast there are results if some ppl are working together :) http://www.midibox.org/dokuwiki/doku.php?id=start We just need to add some extra lines to make this thing work ;) The youTube thingy will be really nice to make great tutorials! I just haven't found out how to activate the sidebar (but don't want to hurry noone, I think it's enough to do to set up a new start page atm)... As I said before, I don't think that pic-uploads are so important, because it has become a really easy task to upload a pic somewhere and hotlink it. So don't make yourself too much work, admins ;) I also like the installed code2 plugin v much! the line-numbering, diff, highlighting, comment functions and the scroll view are great improvements! btw: has the search box results css popup been always there? just noticed this :D best, Michael

It's not that complicated finding a place for some electronics pics; there are a bunch of free image hosters. And the dokuwiki caches the images, so normally there should be no problem with broken linked imgs... Maybe that's a bit friendlier regarding our space consumtion; if I'm allowing ppl to upload something onto our servers, I usually have the problem, that noone of them seems to be able to set the image compression to a reasonable value. You can't imagine how many megabytes a few jpgs can consume :o That would be a good topic for a "how dow I write an article on the Wiki" Wiki article :D Enabling embedding of youtube vids would be nice, because that's not possible atm. http://wiki.symplus.co.jp/computer/en/youtube_plugin Though I don't know if that introduces any security leaks :-\ ;) Cheers, Michael

well, looks good anyway :) I can imagine the starting page will be a lot clearer soon ;D

yipee! :D I believe a sidebar would be a nice thing to improve the navigation: http://wiki.jalakai.co.uk/dokuwiki/doku.php I'm not sure if this is the right one, because it uses namespaces to group items; it might be too much work to convert every document to use namespaces (and I remember Twinny said something about nonworking namespaces somewhen?). But if there's an option to have one editable sidebar (there are examples on sub-pages with an editable sidebar)... hmmm... I also added a new page "start": http://www.midibox.org/dokuwiki/doku.php?id=start just some testings with boxes and how the formatting is in there, though... Cheers, Michael

cool :) I really believe it's a lot less work to integrate the Harmonizer Classes into the Toolbox than to integrate the Toolbox into the Sensorizer. This was not meant as a "pseudo-argument". // globals extern unsigned char base; extern unsigned char scale; // functions extern void ACHarmonizer_Init(void); extern void ACHarmonizer_SetBase(unsigned char value); // sets new base note, 0..127 extern void ACHarmonizer_SetScale(unsigned char value); // 0..SCALE_MAX:scale# or >SCALE_MAX:next extern void ACHarmonizer_ToggleScale(unsigned char direction); // 0:down, 1:up extern void ACHarmonizer_Random(void); // set new random base & scale extern unsigned char ACHarmonize(unsigned char value); // 0..127 in, returns harmonized value [/code] It's all there, you just need to implement the HUI stuff in main.c (or the relevant HUI-/Menu-Files, don't know the Analog Toolbox) I'm glad, too, we sorted this out :) Cheers, Michael

Hi, I don't know if that's biting off more than you can chew, because I don't know you at all. If you're patient, willing to learn or really keen on getting this to work, chances are very likely that you will succeed. If you're tending to give up early and/or hate soldering irons, I would think it over ;D it's really hard to tell, sometimes it works out of the box, sometimes even I am making a (soldering) error that drives me mad. The general building requirements for the ACSensorizer are relatively low compared to other projects, because you just need to solder one Core, one LCD, one DIN and maybe an Interface. I could help you with special questions and am interested on feedback from users; but my time is too short to provide general assistance in soldering or step-by-step instructions ;) But from what I know this forum is really friendly (and it seems you are too :)), so the question would rather be: what have you to loose if you just try it? If you're still interested then I'd suggest to proceed like this: About general start: Check out the Introduction page on the Wiki: http://www.midibox.org/dokuwiki/doku.php?id=introduction_to_ucapps.de then look up ucApps.de and concentrate on MBHP-modules - Core - DIN - LCD - Bankstick There's a small step-by-step building instruction list on the ACSensorizer Doku; I don't know if you have already seen that: http://www.midibox.org/dokuwiki/doku.php?id=acsensorizer_04#step-by-step_building_instructions About the resistance-question: check out the Wiki, there's a sensor page that should contain a link to a forum entry that describes the general principle of how to make a sensor out of a resistor ;) Best, Michael

Michel, I think you did not read my posting right: I have reserverations in forking the Sensorizer, yes, but I even offered you help implementing the Harmonizer-Classes into the Analog Toolbox (which I think is the easiest way to go)

Hey nebula, I think I forgot to mention that I appreciate your work on the wiki v much :) Don't stress yourself, it's a great idea to have a temporary page "home"; I will have a look too and help, but I'm also quite busy atm; I don't think that's very urgent; it's been a mess for years, so a few days more won't hurt ;D All the best for your upcoming marriage! cheers, Michael

I see... Well, the main issues (me having no AOUT hardware) still remain; so unless you don't release a stand-alone harmonizer, I don't have no problems with some decent code-ripping (I love being credited, arrrr ;D) I think it would make more sense to integrate the harmonizer to the Analog Toolbox: the sensorizer software is tied to the AIN-sensors, beginning with the bankstick patches and ending with the menu-control based on selected AIN-pin-numbers... it would require some efford to strip the unnecessary things and only god knows if it would still work afterwards... it's surely easier to add the two ACHarmonizer sourcefiles to a new or an existing project (maybe you also need the ACToolbox and ACMidiDefines, but that should be all). The files are well prepared with accessors to be used without having to change a lot ;) Moreover, I was not very pleased with the situation of the SpeakJet project, which was branched very shortly after I released the first beta sources - anyway, I understand the reasons and the momentary solution is one I can live with. But if I'm honest, I am not keen on repeating this with the ACSensorizer. Gimme a shout if you need more infos :) Best, Michael

ups :-X is this a common expression when it comes to harmonizing (adapting notes to a musical scale)? Whenever I read the term quantizing in menues of music programs, it always meant shifting the notes to the right place in time... :-[

about my solution for quantizing: I am not using any buffers, the approach is quite simple (which does not mean I discovered this possibility quickly ::)) I disabled the AIN-Notification and assigned a countdown-number to each pin, for example 95 ticks for a full note for pin 1. The counters are decremented each clock cycle. When the countdown reaches zero, the AIN-pin is read (and the processing occurs). Best, Michael

I'm really against piracy. Please don't attack ships!

Hi Durisian, it's there, the first two links of the Wiki: - What is a MIDIbox - Introduction to uCApps.de (What can it do) Agreed; that means the projects have to go on top, right below the Introduction Links. I always thought about some graphics or small example pics for the index page. I think this would help the structure, too. Maybe we could also introduce some sort of table to use a column-layout for the front-page? For example like this wiki: http://www.macentwicklerwelt.net/doku.php though it seems that <box> is not supported by our wiki :-\ Best, Michael Edit: it's a plugin http://wiki.splitbrain.org/plugin:boxes

Hi, I already answered in the ACSensorizer topic: http://www.midibox.org/forum/index.php?topic=8401.msg70835#msg70835 in short: there isn't enough space left :-\ But I also proposed: Option 3: Connect the Analog Toolbox to the ACSensorizer Maybe I could do something about quantisation of incoming events (the harmonizer works too for incoming notes which get forwarded harmonized); there may be some remaining free bytes to squeeze that in... :) Cheers, Michael

Hi Neil, I received your contact request, but thought it would be nicer to answer here, in case anyone else is interested, too. In principle this is very easy; though my approach is differing from the Lucky Dragons example: While they are using the human body as a simple resistor that is connected to a (fabric) circuit, this is kind of a human circuit bending. In contrast, I am using the skin as a resistance-based sensor. So I am just measuring the voltage and am producing a MIDI signal by that. This signal gets then translated to music by software synths. As I am working with sensors for quite some time now, I developed the ACSensorizer, which can create Notes or Controllers from any type of connected sensor with quite good control over the connected sensors. Any resistance or voltage-out based sensor can be connected, as long as it does not output more than 5Vs. If it's less, no problem, the Sensorizer can interpolate and scale the input values to a reasonable value. All plans and software are released; and to my knowledge, this is the cheapest but most versatile sensorBox currently available. Nevertheless, you should first experiment with the voltage ranges you can get out of skin contact; I don't suppose it's possible to chain a whole audience, because the connection is always as good as the weakest link ;) I agree to the young manbeing interviewed, who stated that it's best usable for less than five people. This is also my experience. Esp. if there are lots of other sounds, people that aren't musicians (ie trained to hear different instruments) have difficulties detecting their interactions they make. I hope this answers some of your questions. Best, Michael

Hi, I just restored the Wiki to the version where the user projects are still in. I was a bit shocked to see so many informations missing and my first thought was that they'd gone missing accidentially. sorry, didn't see that before. As it's a wiki, you can easily access your last version and update the page from there. But I believe, it's not the right way of simply deleting information without providing alternative access points to the removed information. I agree, we could group the items to subpages, so that there aren't so many links on the index page; but then again, this should be done carfully and by adding other starting pages (eg. Projects -> Sequencers -> ...) and not by removing them at all. Another thought is, that the usability will be reduced if all information is splattered all over different pages; esp. because there's a main menu missing in the wiki-software (yes, there's the trace, but as the trace is every time different, I don't use it very much). An example: The thing with the user projects is, that there aren't just userProjects on the starting page, but only those which are completed, which is a great pro for the community! And you can't tell which projects are completed from the userPages sub-page. If you see this from the eyes of a newbie-stranger: would you dig into the userProject-pages if you visited the Wiki for the first time? I wouldn't. So, if we want to reduce the startPage, I propose to think about adding subpages, for example: - General (containing introduction, general, basics, books, soldering tipps, tools etc..) - Projects (containing synths, controllers, just completed ones) - Hardware (containing parts, modules) - Developers (containing app dev infos) - User Space Regards, Michael

Hi sneakthief, thanks for your input! I have two thoughts on that: 1. I have never worked with AOUTs; I don't even own an analogue synth, nor do I have any AOUT board. This means I do not have the suitable environment to develop this. 2. I have a severe memory space problem regarding new features. The current program grew the last two years and now I reached the maximum available space for the PIC18F452. That means, I will still be able to add one or two lines, but more would make necessary a PIC change... and I guess this would mean a lot more, because it would require to add some menu items as well. And changing the PIC type is a bit of a hassle which I am definitely not going to do if the gain of the additional features isn't really worth all the action. Also: I'd like to concentrate on inputs and sensory readings improvements for this box. If I add AOUT probabilites, the question arises: why not DOUTs, too? So, I get the impression, that what you're describing would be very nice for a seperate box! I don't know if there's a Midibox converting MIDI-signals to AOUTs, but I guess there is. This way you could easily hook them together. Another argument pointing towards this solution is the code integration of the AOUT controls: I would not add the AOUT functions in the Syncronizer Classes like you proposed, I'd add it to the Midi-Classes, where the final messages are being sent. That's another hint speaking clearly for the realisation as a seperate Box, 'cause it shows that the functionality has nothing to do with the code going on inside the box, it would be just glued on the output side. If in this case, any adaption on the midi-output would be required, I'd be very happy to help out and integrate some small additional lines :) Hope this helps, best, Michael

oh :-[ I wasn't my intention to stop this topic from talking, I just couldn't resist to post that pirate smiliey ;D Cheers, Michael

Hi Trent, I'm not very sure about the things I'm going to say, because I haven't really worked with DOUTs so far: MIOS does not support setting a PWM conveniently through a method (though I agree it would be very handy if this would exist - eg: [tt]MIOS_DOUT_PWMSet_Pin(percentage)[/tt] :) Therefore (if you want to use MIOS), I think the trick is to use the ShiftRegister methods and set up a pattern with on/off values to create your pulses kinda "manually". I don't know if the PIC has an internal PWM function that could be accessed by asm; but I guess the approach there shouldn't be so different. I hope I'm not talking rubbish, so if anyone knows better, feel free to add your comments. Best, Michael Edit: Ah, forgot what I really wanted to say: I recently stumbled upon a project using super bright "z power 3 watt LED" that is controllable by 5Vs. The Guy sais it's brighter than 12 normal super bright LEDs: http://tobe.nimio.info/led_mood_lamp.php Not sure though about the requirements of the Power Supply :-\

hmm, just stumbled again over this very nice project... @SmashTV or TK: wouldn't it fit perfectly in the new UserProject board rather than in the news-section? Best, Michael Edit: Thanx, Smash! :)

Hi th0mas, great to hear that :D The ACSim-Files contained in the Sensorizer zip file are probably newer than those on the wiki; if you got too much to do, I'd also be happy if you send me your adapted files and I can merge them and update the wiki (though I won't be able to do this this week, 'cause my 2DO looks probably similar than yours ;D ) Cheers, Michael

thanks Sasa for sharing this info! I do have a microKONTROL for quite some time now and I never noticed that the velocitiy of the pads is restricted... I never had the need to press two neighboured pads at once with a different pressure (besides that this is a quite complex thing to do :-) I think it's a nice way to learn about "efficient" constructions ;D Cheers, Michael