th0mas

Hi Jaicen: I think I see you post a lot on the burnkit site :D, we have some similiar peices of kit! (get a 1-bit groovebox yet? they rock!) Anyways, Another option would be an old palmpilot, a gameboy advanced, or maybe an ipod running rockbox or ipodlinux? None of them probably have precisely what you're looking for, but they're all open(ish) platforms that could have the application built. Cheers, Tom

Yeah, dual switching isn't a feature in C. You can get the same effect by layering your switch statements switch(j) { case 1: switch(i) { case 0: // corresponds to j == 1 and i == 0 } }

It's supported by C, I don't know about SDCC/PIC. See: http://www.crasseux.com/books/ctutorial/Function-pointers.html

Hey stryd :D, I figured you'd show up here. Thanks! Personally this is all I want for a sequencer right now, to be able to sequence painlessly on the fly. I play synth in a electro/rock band, and my MPC does all drums, so this will be easy to fit in and give me the ability to play at least an extra synth part :D. At first it's going to be a single track of MIDI data, thats it. I have to figure out what exactly my PIC will allow, the biggest issue is naturally RAM. For now I don't want to get bogged down in EEPROM or bankstick read/writes, so everything persists in the onboard RAM. Initial settings will have an 'overdub' and a 'replace' mode. It will be smart in relation to CC messages (if the step's buffer is full it won't erase a keypress/release to write a CC message). As mentioned earlier there will also be a button to ignore CC messages from the recorded entry so you can just tweak the knobs. I'm still trying to work out the details of how to buffer steps. Originally I thought a linked list, but the overhead is not worth the adaptability. Then I thought of a static array of the full 24ppqn x 16 notes, but forgot that you can have multiple midi messages per MIDI clock slice. It's a balance between CPU overhead vs memory usage, like anything on the PIC, and I don't know what the balance is like until I have the hardware built and can do some onboard testing. For the first version (I want to play live in a couple weeks) I might just make it monophonic (only save 1 event per timeslice) and use a static buffer. I'm thinking about some sort of heap structure to use space as effectively as possible, but the problem is once you have to store your timing offset in RAM (instead of it being how you determine your offset into your event array) you waste a lot of space.

Exactly, plus whatever quick features I could add by filtering the MIDI data. I plan on having some sort of trigger out to sync it to other gear, like my 1-bit groovebox. Getting it to sync with a looper pedal would be pretty hot. I've had some ideas related to CC filtering (randomization, scaling, etc) but for now I'm just looking at a 4-bar looper that can sync to my mpc and ignore CC at request. For a UI I'm thinking probably four to 6 pushbuttons, similiar number of LEDs. Each pushbutton will toggle a feature, the LED associated will tell you if it's on/off. Plus an LED tempo indicator, that's about it. The version that has a master clock ability will need LCD and at least an encoder, but I'm not as interested in that right now.

Hi Michael, I remember reading you post something about that modification to mclock you made. If you wanted to give it to me that'd be great! Cheers, Tom

Disclaimer: I _really_ try not to post anything, ever, until I've written the code for it. In this case, I'm actually interested in what minimal feature set I should include in my design, so I might as well talk about it as I develop it. I don't consider it vaporware since I need it completed for a show on may 12th in one form or another :). Basically the application is a 4-bar looping sequencer. Based on clockbox, it locks to an external midi clock (I don't really plan on adding support for an internal midi clock as it's going to be always slaved to my mpc), and listens for midi events on a single channel. If it's in 'record' mode, it adds any received midi events to it's buffer and will repeat that note at that offset to the four-bar loop. in other words: you play four bars of music, it loops it. Some added features I'm planning on: * 'ignore CC' - basically it will not bother to play any CC messages that are in the buffer, or alternately not record any CC messages it receives *reverse *invert CC *if there were enough RAM, an A/B mode to have two sequences stored. I don't think so. *sync output for the 1 bit groovebox. I think the target hardware will have two alternate setups: CORE with LCD and 1 DIN (ie, MBSID step A), and also just a CORE with some of the LCD pins stolen for I/O and the midi channels hardcoded (or configurable through some arcane LED representation).

the sizeof is static.. just calculate it and put the value in the code, add a comment at the struct declaration reminding yourself to update the value. edit: or just have a global int that gets calculated at startup char sizeofStep = sizeof(step); then just use that in your additions.. Cheers, Tom

Assuming you're accessing your array data sequentially, you could keep a running pointer to the current step, and just increment it by sizeof(step) to get to the next step. You'd have to do it smart though, since any extraneous variables in the track that aren't part of the steps will need to be skipped over.

I'm going to get things wrong in this post - I don't have time to correct it, but you'll understand the technique. I'm assuming you understand the calculation: n*0x9e+0*0x07+something (ie you realize 0x9e is the size of an entry in the larger array, and 0x07 is the size of an entry in the smaller array). If you wrote a function, something like: step* calcOffset(int n, int m) { return n*0x9e + m * 0x07 } then you could use step* ptr = &track[0] + calcOffset(n, m) or just access it with (step* (&track[0] + calcOffset(n, m)))->something. Will this give you better code? probably not. But see what happens..

Without looking too deeply in the code I'd bet that your problem is arising with the ASM that SDCC is generating. Basically there is probably some very low number of case blocks you can put in one switch/case block. It'll probably have to do with the size of a variable used to calculate a jump table offset. That's just a guess :D. There's an easy solution. Try breaking your code into two different switch/case blocks. It shouldn't affect functionality really. In other words break it like so: switch (case) { case 1: case 2: . . . case x: } switch (case) { case x+1: case x+2: .. . . default: } It's probably still not a robust solution. but if it works, who cares :D - judging from your previous posts you will be playing it on stage while most of us argue about what is the best implementation in code :D.

all mine is, is a little groovebox that isn't more than an atmega32 and an amp. Just wondering what you guys have done in the past. I'm not performing, I saw an electro act in mtl last week and after talking to one of the guys, decided to build him one of these grooveboxes and give it to him when we're both at coachella in LA at the end of the month.

I'll do that, post whatever they say here..

Hi everyone, Anyone have any tips for crossing borders with DIY gear? I'm specifically flying from Canada(Ottawa) to LA with a relatively simple synth (mostly just an AVR processor) and am wondering if I can do anything ahead of time to ensure a swift customs visit. Cheers, Tom

If you're doing very electronic sounding music such as house, a big tip is to tweak your kit CONSTANTLY, albeit slightly. Listen to Daft Punk's Homework as inspiration. They can play the same 909 groove for 10 minutes but it still kicks because they're tweaking the sounds in every bar. That's what I try to apply to my music I've been working on lately: take the time to tweak the parts throughout the track, even if it's the same pattern being played repeatedly. Your brain will thank you and not get as bored :). Other than that, again this is in reference to electronic drums: you can do a whole lot with compression/eq/filtering. Take Reason for example - all the samples that come with it sound like shit, but you can take any of the weak bass drums, compress it, add a bit of distortion and then feed it into an LFO and you have a monster kick at your disposal.

1-bit groovebox

Hey guys, this weekend at my girlfriend's we're having a "40's and arts and crafts" night, and I know at least some people are making stuff out of clay and then oven baking. Any instructions for doing a didj with that method? I'm a canuck but would love to try that :D Cheers, Tom

Hey guys, I'm sure you aren't, but just to wrap up this thread here is a picture of what I ended up giving her (only a couple days late, too! whew!) Her description of the picture: "happiness is BEEEEYYYYYSQUEEEEEEEEEEEeeeeeeeeee!!!YYYOWWWBBRRRRRRDDDDDD RRRRRRRRRRRREEEEEEEEEOOOOOOO " and she says thanks for answering my questions :D Cheers, Tom

If it's a type mismatch bug, it could be because you are passing it a variable of type char[] and it wants char*. They are identical except some compilers will complain about it. Just cast your array to a pointer like MIOS_LCD_PrintCString((char *) text); Most likely the 'code' keyword is just a hint to the compiler to say where the memory for the char* is coming from. I don't know the details and what limitations it enforces however, but try just typecasting your array as a char pointer first.

A good start would be clockbox, then define some struct to hold your (timed) midi events. I believe clockbox keeps track of bars/steps, which you could use to index your array of events.

Compared to the design of the Core PSU, if I know that I'm using a DC adapter for power, can I get rid of the bridge rectifier and the 2200uf cap? I might keep the bridge rectifier anyways just to prevent the inevitible soldering things backwards..

Having seen: http://compiler.kaustic.net/machines/apc.html I'm thinking about integrating this into her gift - she likes things that go beyoowoooppppp. AFAIK the circuit is basically two 555's, with one of them controlling the other's oscillation frequency or duty (or both.. or something). Could I integrate the LED into the controlling 555's output so it also flashes while modulating the second 555? I figure it might work since the frequency will be low enough to be visible (I think - I'm going to have to analyze the circuit to guarentee that).

I actually already have the 555 circuit built! Thanks for this option though, I might look at it for some other ideas. Now to tweak my resistor values!

Thanks! I'm actually going to try the capacitor across the LED first, I think the sudden on/decay might actually look cooler than fading in and out - but I'm glad to know if I'm not happy with that I can substitute op-amps :D

If I understand correctly, the capacitor will make it so that it comes on at full brightness and then fades off instead of turning off abruptly? That would work pretty well, I don't really need to ramp into it. Thanks! ;D