istephen

Finally got round to testing the new versions, and they seem to work great on MacOSX 10.3.9. thanks Ian

Start with an A power chord: 5th fret on bottom (fattest) E string 7th on A (next) string) 7th on D (next again) string This is your lifesaver - bluff yourway on electric guitar chord. It's the only one you need... Unlike keys all the frets on the guitar are equally spaced (1 semitone), so move down to 5/7/7 (just moveyour entire hand, keeping your fingers in the same shape) and youve got a G (two semis lower). You can also move it up a string so you start on the A string X/5/7/7 which is D. Practise moving them around so you know how to find the different chords and how different movements sound. Get comfortable with it (perhaps the most critical part). The chord can operate as major or minor, so you can play it over anything - stick a bunch of distortion and reverb on, add attitude and you're good to go :-) Once you've got that down, you can start mixing in more complex chords Ian

I hadn't thought about LED's for the CC switches - in my version they'll be external pedals so I can put the box on(or in) a rack/keyboard and have pedals on the floor switching them, so led's would be unnecessary, but it would be pretty trivial to add an LED out which just reflects the state of all the switches. To do that you'd need a DOUT module (which I don't have), but the software would function the same with or without one. Ian

I'm currently in the process of putting together something not totally dissimilar, though I'm intending to use mine for keyboards - the point is that its still controlling parches, and cc's for live performance on a song by song basis. Hardware wise you need 1 CORE, 1 DIN and 1 AIN modules. You could almost certainly get away without the AIN, and perhaps even the DIN if you limit the switches, but as the AIN is about 7 euros I figured it's not skimping and between them these will allow you more buttons and pedals than you'll ever need for this. Software wise, I'm envisaging a song up/song down switch so that I can program in a set list, and when a song is selected a set of patch changes gets sent out reprogramming every device. It'll also respond to midi-in patch changes so that I can select songs from a keyboard. The other way to select songs (which I think would be quite neat) would be to have a song-select pedal, and when that is pressed playing a note on the keyboard selects a song rather than making a noise. I'm not envisaging any explicit program select buttons, as my set up is too complex to mess around selecting individual patches live, rather you select a song, and then have CC's to modify that, but it would be a trivial change. For each song there'll be a mapping from switches and pedals to CC's on various channels, so for each song the pedals get reprogrammed to do the right thing. As I'm using keys I also want to do mapping of notes to channels for each song, but that's not much use for guitar. My current status on the project is that the core hardware is under contruction - I bribed a friend to do it, as they'll do a farbetter juob of the build than I would. I've set up the dev system, and build a few test apps, and once the hardware comes back it should only take a few days to get a prodotype running (I hope). Ian

The best option would be to grab sccp and gpasm for windows, and see what builds with that toolset (and how important the source to the problem apps is to you). If it builds with them on windows, then you can build them on Apple or Linux (or anything else for that matter). It's probably a minor job to update the older apps to work with the open source toolsets, but you can at least try it out on windows, and figure how much work it will be. Perhaps TK could give his opinions on the direction he's heading, but I'd guess most new stuff will probably compile with these tools, so this should be less of an issue in the future. Ian

Some of the older apps (and probably mios itself) require the windows devkit. However the newer stuff (and particularly the C API) is based on gputils, and scpp which (appear to) compile and run fine on apple. I've built the various C apps, on MacOS without trouble, though I haven't actually tested the compiled sysex files, as my box is still under contruction. Ian

Hi, I'm just starting writing a bit of code for my midiBox (currently under construction). I'm working in MacOSX, so converted the batch files to a makefile which seems to work well. I've attatched the makefile I used to compile the analog-toolkit. To compile others, just check the defines at the top match those in make.bat, and set OBJS to match the file list (adding .o on the end). You don't need to include mios_wrapper, or pic18*.o, as the makefile adds them in automatically. You may need to use gmake, rather than make if you're running this on other platforms. When I compiled a few things the hex files were SLIGHTLY different to those included in the package. This may be due to a different build of the compiler/assembler, or maybe just some config options. I haven't been able to test any compiled apps, as my hardware is still not ready. hope others find this helpfull. Ian p.s. watch out for the tabs - that have become spaces in the html version. If you copy/paste this you'll need to turn any spaces at the start of lines into tabs, otherwise it won't work. PROJECT=project MIOS_WRAPPER_DEFINES=-DSTACK_HEAD=0x37f -DSTACK_IRQ_HEAD=0x33f SDCC_DEFINES=-DDEBUG_MODE=0 OBJS=main.o aout.o midi.o lfo.o eg.o map.o # === general settings ====================================================== CC=sdcc CFLAGS=-S -mpic16 -p18F452 --fstack --fommit-frame-pointer --optimize-goto --optimize-cmp --disable-warning 85 --obanksel=2 -pleave-reset-vector ${SDCC_DEFINES} FIXASM=perl tools/fixasm.pl GPASM=gpasm -c ${PROJECT}.syx:${PROJECT}.hex perl tools/hex2syx.pl ${PROJECT}.hex ${PROJECT}.hex : ${OBJS} pic18f452.o mios_wrapper.o gplink -s ${PROJECT}.lkr -m -o ${PROJECT}.hex mios_wrapper.o pic18f452.o ${OBJS} #=== assemble MIOS SDCC wrapper and device specific setup ================== mios_wrapper.o : mios_wrapper/mios_wrapper.asm ${GPASM} ${MIOS_WRAPPER_DEFINES} -I mios_wrapper mios_wrapper/mios_wrapper.asm -o mios_wrapper.o %.o : %.c %.asm : %.c ${CC} ${CFLAGS} $< -o $@ ${FIXASM} $@ %.o : %.asm ${GPASM} $< -o $@ clean : rm -rf *.o *.asm *.lst ${PROJECT}.cod ${PROJECT}.hex ${PROJECT}.syx ${PROJECT}.map

Again I'd sugguest some people here ACTUALLY READ THE GPL. It specifically limits the original names legal liability for such stuff. It asserts that the name provides no warranty or support. Anyway only an idiot would try selling even a fully assembled box with a homebuild PSU. Wallwarts suck but they were invented to specifcally allow manufacturers to avoid high voltage safety restrictions. This is a slight grey area - I'd need to go back and check the licensing terms more closely... Most software which is designed to be used as a library is released under LGPL, rather than othe original GPL. LGPL specifially allows code and applications which are layered on top of the licensed code to be free from restritions - eg you write something which uses the GCC C++ library, then you can do what you like with your code (you don't need to release it). The original GPL is less explicit, and I'm not sure it's clear... Given the way that applications are downloaded into the system via sysex SEPERATLY from the OS, I think a case could be made that you're free to write your own apps, and keep the code private - he distributed hex/sysex does not contain GPL'd code. MIOS is not part of your programs, but rather a seperate artifact. On the other hand if you argue that MIOS and it's apps are inseperable then any app you write would have to be release under GPL. The reason I asked for clarification is that the GPL licensing is a bit half hearted - it isn't clear that the GPL applies to the circuit designs, and a few more explicit references rather than just the src download page would be clearer. A copy of the GPL license should probably be included (at least) in the mios binary and src downloads, and a clear reference and link to it should be in the main project pages. Ian

Can I seek a clarification here: The project is released under GPL? As a follow up question - how many of you have READ the GPL? If this is the case then there is no "but we don't want you do to Xyz with it". It's been released as FREE as in speech, not FREE as in beer. The GPL allows you to use the code FOR ANY PURPOSE, not for any purpose unless we don't like it. Anyone is entitled to build any product based on any GPL'd designs provided they publish any modifications, and provided access to the original material. The whole point of gpl is to PREVENT a group of people holding the intelectual property to randsom - which is exactly what some in this group are sugguesting should happen. If for example someone wanted to sell kits of parts, they can read the parts lists, make up some PCB's and sell them for the cost of their materials plus a reasonable charge for their time. This has happened, and it IS A GOOD THING. Smash and others add value to the project by doing so. The GPL allows them to make a profit, but prevents them from exploiting the project, because if you think they're charging too much you can buy your parts elsewhere. If someone buys a kit, and spends an hour assembling it, why shouldn't they charge $20 for their time? If you think thats too much and they're "profiting from the groups work", then the GPL means they have to tell you how to build your own. They can only profit from the VALUE THAT THEY ADD. A source of pre-assembled modules would be an excellent thing for the project. It would dramatically increase the number of software developers who could contribute to the system. If you think the seller is exploiting the project by charging too much, and doing no work themselves, then undercut them and have all that profit for yourself. Ian

Check the thread: AM's digital/analog polysynth project They're doing similar things but at audio frequencies which is much tougher. Should be easy enough, but it's a bit out of my depth just yet (I'm still working at the design phases of my system). If you've got a box set up, it should be pretty easy to start experimenting, and get something running - certainly the entire project would be much simpler than the BIG apps (like SEQ or FM). Just start simple (like a simple speed sweep of fixed amplitude and rate), then start adding stuff. Ian

Should be fine... It's probably worth seeing if you can set up a test system to see if it performs to your needs. It would be interesting to see a midi monitor which could measure the percent of bandwith used, and worst case latency (longest time since the input queue was empty), as this would tell you exactly how hard you were pushing the midi cable, and how much capacity was left. How about a midibox? It's more programming than hardware, but you set up something far more controllable than an lfo. You could set up a sweep system which has three pots for start, end, and speed, along with a trigger button to start it. Better two trigger buttons - one for a one time sweep, and a second to start a sine wave (which keeps running until either button is pressed again). If you needed to you could output the result via an aout module (ie as a real lfo), or just send it directly via midi as a CC (which is where you want it to end up). Once you can generate it sending it via Aout or midi is pretty similar, so you could code it to handle both options. You could integrate it into the existing software or you could more easily build it as a standalone system - a Midi-LFO box. Ian

It should be pretty trivial... Looking at the patchworks you can just lift the part of the circuit that's in the middle right (the relays and everything to the of them). That handles all the switching - everything else is just control circuitry which you can handle with standard modules. In fact that circuit is pretty modular - there's the input, and then four subcircuits which each handle one loop. You could build a tiny circuit to handle one loop, and then duplicate it as many times as needed. You simply need a core and a dout (you could probably skimp on this, but probably not worth it). One dout drives one loop, so you can scale the system as large as you need. You will need some programming it it's very simple - like 5-10 lines of code! Just wait for a midi event (patch change), and depending on the number you get send a different value to dout. To keep it simple you don't need to make the device reprogrammable from the front panel, but rather can write a new program and download it to set up new patch configurations - I'm assuming the whole point is that there are a few basic setting you want, and these aren't going to change. You can add patch programming (either via midi or buttons latter), and get as complex as you like, but you can start simple... The patchworks is basic in that it just has four loops that get switched in and out, without options to change the order, but if you've got the relay swiching board working for one pedal you can just make more to generate some REALLY complex systems. Ian

The difference is how FAST you can wiggle it ;-) By hand you can wiggle a couple of pots back and forth couple of times per second (2pots x 2 wiggles = 4 wps). With an LFO you're potentially doing that hundreds or thousands of times per second, and you could apply this to LOTS of inputs simulaniously. It's been sugguested that the system can handle about 60 wiggles per second (1 wiggle per second = 1 Hz in tech speak). Provided you're total amount of wiggles doesn't exceed that it should be OK, so you could wiggle 6 pots 10 times per second, to 60 pots once per second. You'd probably want to err on the low side, as it would totally mess with the timing of any other midi data going over the same cable (or better yet run one cable just for this data if possible). I think the confusion is in the term LFO - in synth terms an LFO could easily generate too much data, but a V(ery)LFO would be fine. Ian

Thanks for clarifying this. Multiplexing like this wouldn't help with midi conguestion, as say you wanted to layer a sound on two modules you'd still need to send it twice, and it would take just as long as sending it on two channels down one cable. The same amount of data still has to go through the uart. However... suppose you had 8 midi outputs, all wired in parallel. Add an 8 bit latch and 8 And (Or? are the isolators active high or low?) gates. Anyway you could then have each device on it's own cable, listening on channel 1. When you receive an event you look up a channel mask for that event, and load that into the latch, the output of which gates the signal to each midi out. You could then layer a sound on 8 devices by sending it once, or send it to any subset of devices with little overhead (other than waiting for the stream to flush). On the other hand this is problematic for devices which are themselves responding on multiple channels, as the software would need to find a neat way of selecting devices by both device and channel (so for example sending to all ch1 devices is easy, but sending to midi1/ch1 and midi2/ch3 is a real pain). I'll probably just do a soft solution first with one midi out, but I think this is could be a neater solution than having to deal with it in software. Ian

You'd need to consider what happens when the string hits more than one fret - it's gonna happen sooner or later. In the worst case - hitting the first and last frets simulaneously, you would more or less short out the resistor ladder with the string. This would be bad. To solve the immediate problem of causing damage to the 5v surply, you could add a 10K resistor, so that even then the ladder is totally shorted, it's still not drawing more current than is acceptable. Ian