Search options (Page 18 of 40)

Mate, please put one of these boards aside for me. I've got too much on my head right now to dig into this, but I will eventually

Yes, pretty much anything that runs on the micro:bit should run on the Calliope mini. It's the same base board with some stuff added such as motor control and a microphone.

Aww yis time for some Sleizsa torture mwahahahaa

Hehe, I'm actually sort of working for the micro:bit's German sister project, the Calliope mini. It's quite a curious setup. They're somehow super powerful and super lame at the same time. The need to deal with an operating system (3 layers of OS actually, as there's the Microbit runtime running on top of ARM MBED running on top of Nordic's nRF stuff) poses some rather unique challenges xD
I could rant about it for hours but in short my verdict would be: It's great for educational purposes, but for actual development I'd stick to either Arduino or RasPi, depending on the scale of the project.

Thanks guys I actually started to work on an engine to encorporate this a while back, but got a bit stuck while trying to reduce noise. I do want to continue with this at some point though. But first, I'm off to my traditional end-of-the-year trash album recording session.

Shiru: Interesting find! I'm especially intrigued by the noise/hihat sounds. Say, didn't we have another thread for this stuff? Can't seem to find it now.

'ere we go: https://github.com/utz82/bintracker/releases/latest
Just a bunch of bugfixes for now. I might do another bugfix release shortly but I'm afraid I won't get around to implementing any major new features before the end of the year, unfortunately.

Ok guys, per popular demand™ I've swapped Ctrl+V/Ctrl+P in trunk
gtap, are you on Linux or do you need a Windows build with this change?

Cheers gtap, glad you enjoy the ride so far

Yeah, unfortunately the fxtables are not very convenient/user friendly at the moment. My plan is to improve the situation with the next MDAL standard. The idea is that there'll be seperate tables for notes, dutys, etc. on the front end, and libmdal will generate the actual data tables from those input tables. Still got quite some work left on that, though.

This is on the to-do list, not just for the current block but even for the current row. However, it's not so easy to implement. For "normal" chip editors it's fairly easy because you can determine the current playback position simply by counting the vblank interrupts that have occured. However, for 1-bit this isn't possible because in most engines, there are no interrupts.

Good one, haven't thought of that before.

Do you think ctrl-v and ctrl-p should be swapped? I thought that having ctrl-v insert and shift the stuff after the cursor would be more intuitive. But I'm open to suggestions here, in any case.

This would be quite difficult to implement as such, because internally, modifiers don't exist as a seperate entity. However, I see your point and I'll try to find a solution/workaround. Need to dig into the code for the modifiers anyway because there's this problem that heoretically you should be able to enter modifiers without an associated note value, but it doesn't work

Not sure I understand the question, but have you filled all 4 positions on the current row of the sequence? If you have gaps in the sequence, like this:

00 01 -- --
02 -- -- --

there will be random notes and effects.

Yes, that's the idea - except it's not a sample, it's generated in realtime!

Anyway, getting closer to a two-channel implementation. Still need to get rid of some 20 t's of overhead, though.
Ultimately it'd be great to come up with a more efficient way of implementing this, because even just some simple additonal modifications of the delay line can go a long way with this algorithm. Also, using a non-random source (for example a square wave) can produce some great result as well, but again takes too much time with my current implementation.

Edit: Probably the way to go forward is to render at a lower rate. Did some tests with rendering at 7812.5 Hz, it sounds not too bad (and will give more flexibility I hope) - see test2.tap.

After seeing this, I was curious if this type of physical modelling could be made to work on beeper.
Well... I guess it can. Voilà, a real-time synthesized string instrument on beeper
This is only a single channel implementation, but there are 79 cycles wasted, so hopefully 2 channels of this will be doable. Another problem is that right now this works only with 8-bit dividers. It would theoretically be possible to go up to 9 or 10 bits, but this would cost a lot of cycles.