Search options (Page 18 of 41)

If you know how to apt-get, it's actually quite simple.

1) sudo apt-get install pasmo git
2) cd path/to/where/you/want/to/have/houstontracker
3) git clone https://github.com/utz82/HoustonTracker2.git
4) ./build.sh

That's all. If ./build.sh will not run then do "chmod a+x build.sh" before step 4.

That said, I have version 2.30 ready and will release it in a few days.

For your needs, TI Connect is perfectly ok. It's mainly TI-82 users who will have problems with it.
Ok, so regarding the high frequency problem, I can only say hopefully things will be better in the upcoming version. Until then just use that mini-mixer ... I always put a bit of EQ on as well. TI isn't like, say, Gameboy, where you can have good sound pretty much out of the box.

By the way, if you are a Linux user, building the development version of HT2 is pretty straightforward. However, at the moment the keyhandler is somewhat unstable. Once I have fixed it, I will provide some new beta builds on here, too.

That's basically the idea behind engines like zbmod. Or, more relevantly, when talking about pulse interleaving, octode2k16. Interleaving of the various pulse trains is abstracted into an actual calculated output weight. So far, so good.

However, there are side effects. If the channel weight is kept near the maximum for consecutive loop iterations, the speaker membrane will build up additional pressure because there is not enough time for it to return to it's rest state. You can hear this clearly in o2k16, when all or almost all channels are busy. I tried to abuse this effect as an engine feature, but it is very hard to control.

When doing actual interleaving, this problem is much less pronounced, since most often there will still be long enough periods for the speaker cone to retract even at when channel weight is high. So by interleaving two "binary trees" (like in pytha, for example), we can mitigate the "ramping" issue, while still maintaining a sizeable number of possible channels. However, this also has side effects, as demonstrated here: http://randomflux.info/1bit/viewtopic.p … 1396#p1396 I still haven't figured what exactly is causing this phenomenon. My guess is that possibly the common assumption about using 8t alignment to mitigate IO contention is not correct, to start with. But probably that isn't the whole picture either. I do want to investigate further with a "perfectly aligned" engine at some point, though. Just need to find some time and motivation for it.

Thanks for the fixes, Shiru. Is the issue of clicks in 3rd channel fixed in your version? If not, how can I reproduce it?

Great stuff indeed! Very quirky and unique. I like his other stuff as well.

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.