Messages

61

General discussions / sfml + librubberband: a small experiment

« on: December 29, 2012, 10:28:56 am »

Hi everyone.

I recently did a little experiment of trying to inject librubberband into sfml. For those of you that don't know, this library is for time stretching/pitch shifting, and what I wanted to achieve was true pitch shifting, ie. not just 2x faster playback at 2.0 pitch. What I was able to do so far (not much lol) is on this github fork ("rubberband" branch). Basically, you can load up a sf::Music, set the pitch, and play it back.
What doesn't work:
 - Changing pitch safely during playback
 - (Probably) seeking

Also, there's a weird sound fragment coming up when a looping track rewinds to start.. don't really know yet where that's coming from. The quality is.. well, not too good, but we get this much without doing any previous preprocessing-pass (pitch is shifted on the fly). I could try and add a pre-pass, but that would delay playback by a couple seconds, which is not nice. Also, I will need to try out some other fine-tuning parameters for rubberband.

So, is there anybody else out there who ever trying getting correct pitch-shifting working on sfml? Or is there possibly a far easier way I just overlooked all the time?
I think I really do want this feature (for myself), so I might work a bit more on it later (also for sf::Sound). I'm not really sure what to do next because I have absolutely no experience in digital audio. =P

Edit:
Oh yeah, actually I was hoping that sfmidi would work with my changes out of the box, but somehow it doesn't seem to work at all. The way I understand it, sfmidi preloads the entire audio data into RAM, and then just feeds that into the stream.. is this wrong? I can't seem to figure out what's wrong..

By the way, because I absolutely suck at build systems (qmake is the only one I barely manage to use), I didn't integrate librubberband via cmake or anything, so when you link against the SFML libraries built from my tree, make sure to add "-lrubberband" to the linker flags.

62

Feature requests / Re: Non-const access to RenderTexture's texture?

« on: December 26, 2012, 09:54:04 pm »

It's a bug, it should be added like setSmooth/isSmooth. If you need it you can const_cast what getTexture() returns and modify the internal texture directly. But remember that it's ugly, it's only a temporary workaround until it is properly fixed

Ah, okay, cool thanks ^^ I'll do that.

63

Feature requests / Re: Non-const access to RenderTexture's texture?

« on: December 26, 2012, 08:27:24 pm »

A RenderTexture is not a texture, it creates a texture as a result of draw calls. You cannot play with the internal texture; you're not even supposed to know that there's one, it could perfectly be created only when you call getTexture().

Okay, good, so my assumption was correct, there is a technical reason the texture reference is const only.
It's not really a show stopper or anything. I just thought I could be a little bit more efficient.

I don't know why all your textures have to be a render-target, but this is not how the RenderTexture class is meant to be used. Maybe you could explain us what you do with textures?

Well, I need to implement this interface. At first I was going to use sf::Image for it, but for a couple reasons (ie. stretched blitting, text rendering, hue shifting) it is more efficient to do everything directly on the GPU.

Edit: Oh, almost forgot. Is there a way to render the results of a RenderTexture in repeat mode,
without creating a copy of the internal texture everytime?

64

Feature requests / Non-const access to RenderTexture's texture?

« on: December 26, 2012, 06:21:23 pm »

Hi!
I'm not really sure if there is a deeper meaning behind RenderTexture's getTexture() call only returning const
references, but it is something that I keep having to work around.
Because almost all textures I use must support being rendered to,
they're RenderTextures by default. This however makes things like
initializing from image files, where I have to create a throw-away texture,
unnecessarily wasteful, and some things, like setting repeat mode,
apparently impossible (?).

Is there a technical reason why the internal texture cannot be manipulated
like a usual texture?

65

Window / Re: Is Xlib fix for threading still relevant?

« on: December 24, 2012, 10:24:34 am »

Okay, thanks^^

By "fixing", do you actually mean the switch to xcb?

66

Window / Is Xlib fix for threading still relevant?

« on: December 24, 2012, 09:20:25 am »

Hi! I recently started working with SFML, and I must say I enjoy it very much^^

When I split off event handling in my project into a separate thread,
all sorts of weird would happen, from bad X request errors to hanging in a window.clear() call.

This patch fixes those issues, but I was wondering if I should even create a pull request for this,
as it seems the relevant parts will soon be replaced by xcb anyway?