(14 replies, posted in Sinclair)

Hey, I like your mp3 entry! And massive props for that Earth Shaker track as well.
Squat is great for me, as it enables me to get stuff done quickly. Somehow it reminds me of the days when things were simpler wink but then with great sound and sampled drums. I might have a bug report though (1tracker keeps throwing "engine provided no data" errors at me), but I'll check if it still happens in 0.29 first.

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 wink


(14 replies, posted in Sinclair)

Ha, nice. Yeah, DiHalt beeper compos were quite good in recent years (except last year's Lite edition when I was the only one to submit). They better send me a diploma this time, though wink Anyway, thanks to you, Shiru, for that awesome Squat engine!

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.


(5 replies, posted in Sinclair)

I'm mostly interested in the 3rd approach, especially in combination with multi-color gfx. To me this combination totally makes sense because both these things require exact timing. I'm also curious how a perfectly timed engine would sound in the first place. Did some tests with this back in November but didn't manage to complete anything before leaving for Germany.


(2 replies, posted in Sinclair)

Aww yis time for some Sleizsa torture mwahahahaa


(14 replies, posted in Sinclair)

Tee hee seems we were having ourselves a nice 1bitforum battle this time yikes

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.


(76 replies, posted in Sinclair)

Wow wow wow... massive thanks for all the work, Shiru! And sorry for the radio silence, I had no internet access for the past 5 weeks. Now catching up with all the stuff I've missed. Will write more later.

I think it should be possible to fix the makefile to handle 64-bit compilation. Though as a lazy fix, I guess forcing 32-bit compilation on 64-bit systems would do, as I doubt 1tracker will benefit much from having access to >4GB of RAM.


(82 replies, posted in Sinclair)

Thanks guys wink 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.

Hehe, sounds good to my ears big_smile
Haven't heard about the Lunchbeat before. Is it in any way related to Noah Vawter's 1bit Groovebox?


(51 replies, posted in Sinclair)

'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.


(51 replies, posted in Sinclair)

Oh, I sure like the sound of that... seems you're indeed having fun with that engine! <3
I've discovered a few new bugs while testing yesterday. I'm gonna have those fixed asap (hopefully tomorrow) and then I'll upload a new Windows build, ok?


(51 replies, posted in Sinclair)

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


(51 replies, posted in Sinclair)

Well, originally I had Ctrl-V doing a "paste and overwrite", and the current Ctrl-V "insert" behaviour was on Ctrl-Ins. However, it appears that some newer laptop keyboards don't have an Ins key anymore (whoever came up with that bs?), so those users would have to press some akward combo involving the Fn key. Anyway, that's how the current situation came about.

I have to say that to me, the current behaviour seems more logical. If you press Ctrl-V in a text editor, the stuff after the cursor will be shifted. So that's what "paste" means to me. And of course in a music editing context, the term comes from tape reel editing. And in that context, paste means inserting a piece of tape, as opposed to "paste over". So in my opinion, having Ctrl-V paste over is wrong. However, I just checked the docs of various trackers and it seems the majority indeed does a paste-over on Ctrl-V. Guess that's what you get when 99% of tracker authors are non-native English speakers... So I suppose I should indeed adapt *sigh* wink


(51 replies, posted in Sinclair)

Cheers gtap, glad you enjoy the ride so far wink

gotoandplay wrote:

Thx also for the examples, as I wasn't sure how to use the fxtables until I looked at those.

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.

gotoandplay wrote:

suggestions so far would be

-a way to know which current block is being played back.

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.

gotoandplay wrote:

-shortcut to play a block from a selected frame rather than the very start of a block.

Good one, haven't thought of that before.

gotoandplay wrote:

-i miss ctrl-v being ctrl-v ;( but ctrl-p is just as good i guess tongue

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.

gotoandplay wrote:

-a way to select, copy and paste note modifiers on their own (independent of the notes)

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 yikes

Ha, totally forgot to reply to this. I've actually experienced this kind of road before, think it was in Norway. Imo the result is not that impressive... but yeah, I guess it's mostly about the spaces between the gaps, so it's a kind of pulse frequency modulation wink So indeed, some 1-bit trickery could work.

In it's most basic form, this technique is actually getting quite common nowadays on highways, to alert drivers when they are going over the side line.

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.


(82 replies, posted in Sinclair)

More progress on this. Seperated the code that generates the attack transient, so it's now possible to use arbitrary source material. Attached example uses 50:50 square. 2 channels @ 7812.5 Hz. Some parasite noise remains, I'm afraid it'll be difficult to reduce it further.


(82 replies, posted in Sinclair)

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.

Awesome! I think I'll be needing one of those as well...
What's the tune from 0:30 onwards, don't recall hearing that before?


(82 replies, posted in Sinclair)

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 big_smile
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.


(51 replies, posted in Sinclair)

Thanks! No need to run it on your other machines actually, it was just to rule out that there's an OpenGL-related problem at hand with this issue.


(51 replies, posted in Sinclair)

garvalf wrote:

I have also an other bug, even from the beginning, sometimes the screen is mixed up when I start bintracker:


when I pass the mouse over a mixed up icon, it displays just below the menu, it's just shifted. It happens at random.

Need your help again wink Could you run

glxinfo | grep OpenGL

on the machine that has this problem, and post the output?


(51 replies, posted in Sinclair)

I think the "don't save" option is pretty bad, so I definately want to solve it for MDAL2 wink Should be doable considering the whole thing is gonna be rewritten from scratch anyway.

Regarding "labelled" blocks, I have to see about it. I like your idea, but on the other hand I want to avoid "special" cases as much as possible, to keep the parser fast and light-weight. So from a technical point of view, it would be better to do this:

   NAME="my super catchy intro"

where NAME is a block constant, that is a command that can only be set once per block, and doesn't count towards the block length. Theoretically those exist even in the current MDAL standard, but aren't handled by libmdal. Which is another blocking issue towards adding support for various engines...