Search results

I just noticed this thread had moved on without notifying me, even tho it says I'm subscribed to it :) Great news that the touchscreen might be available now. However, I did quickly tried: CODE case SDL_MOUSEMOTION...

nice neutek, try to get a recording ! Thanks, it was done on a GP2x, I do all my tracks with it. Not that it really matters coz they have exactly the same capabilities. If you want to dig around, all tracks on hexawe have the projects there too so you can download and learn/alter ;) Cheers Marc

Unfortunately, due to too much problem to deal with the hardware, the GP32 has been ditched :(

LittleGPTracker 1.0 is out ! Even on cracked and worn out GP2X, the pig still rox the block ! Here's a rough cut of the features since 0.52a: + Sample library & import support + Groove support for odd time signature + Debian build + Allows creation of project from the program itself + new...

yo paeryn, since I've upgrade with the touchscreen enabled version of SDL, touching the F200 screen crashes lgpt although I don't even process mouse events. Any idea from where it could come ? Cheers Marc EDIT: fuck GPH for killing the usb network !

looking that the source code, I realised 1bpp seems to need 1byte per pixel. However, it still doesn't work

Did anyone succeed to use 1bpp surfaces ? I'm trying to speed up the drawing of my fonts using them combined with SDL_GP2X_SetMonoColours My font is 8x8 so for each char I do: CODE fonts[i] = SDL_CreateRGBSurface(SDL_HWSURFACE, 8, 8, 1, 0, 0, 0...

That'd be fun indeed but I'm not really organising anything myself.. rather take opportunities when they land :) where are you now ? still in london ?

That sounds ace ! I gotta keep that naming.. it's nice.

Funny to see that anybody playing music in front of people is assumed to be a DJ. :blink:

Enjoy the pig on major P.A. :) http://www.youtube.com/watch?v=pEvFLi0iLRE

It's out of my reach really but I know having a long discussion with a guy way into filter modelling and that's what he told me. It's related to non-linearities in the process but I won't be able to explain that to you myself.

You're talking about the direct 'result' ... i.e the sound stream output and for that I pretty much agree (although 32k is pushing it) but you can have higher order effects that do have a result in the audible range (i.e. 44.1 in our case) but don't 'propagate' properly unless they are computed...

As far as I could grasp it, the most important with respect to "sampling frequency" is the internal computation. A filter treatment will allow a lot more subtleties if run at higher frequencies... of course, it means better resulution/accuracy but true 'analogish' modelisation needs very high...

Well I thought I did, but obviously I blanked out some parts... sorry for the garbage. Exellent news, this could take littlegptracker to some new grounds.

But you can have usb one right ? please don't tell me audio & midi usb will not be supported ... pretty please?

You'd be surprised how much "synthesis" you can do from samples already. BTW, if any of you owns a GP2x and is not aware of it, check http://www.littlegptracker.com and some of it's results @ http://www.hexawe.net

Although it seems to work, this code is extremely slow compared to reading /dev/batt. In lgpt, reading it constantly in the playback loop breaks the smoothness of the program. Is there any alternative or do I need to check it only 'so often' ? Thanks Marc.

At a certain point, I'll definetly give pandora a go for porting LittleGPTracker. What holds me at the moment is that I'm not sure about the sound support in the machine for 'real time' processing. The GP2x works wonderfully well but for example the EEE, although about 3x more powerful...