DeviceAudioRt::soundStop stops slot, not handle (?)

[mgmeier]

The function looks like this, and what it seems to do, is treating the sound handle as an index to the playable/playing slots:

bool DeviceAudioRt::soundStop(unsigned int sound) {
    if(!sound||(sound>m_nSound)||!ma_sound[sound-1].isPlaying) return false;
    ma_sound[sound-1].isPlaying=false;
    return true;
}

The sound, however, might be mapped to any slot (the first one found free in soundPlay, e.g.). Shouldn't the function do something like this instead (snippet taken from DeviceAudioRt::sampleDestroy) ?

map<unsigned int,AudioSample*>::iterator iter=mm_sample.find(sample);
[...]
for (unsigned int i=0; i<m_nSound; ++i )
    if(ma_sound[i].sample == iter->second)
         ma_sound[i].isPlaying=false;

[csabahruska]

It seems that I did not understand the C++ API and its abstractions correctly. I missed the fact that the sample and sound handles are distinct things. The sample is a shared data resource, while sound (handle) refers to an active track. I have to update the Haskell API. Thanks for reporting this.

[csabahruska]

Fixed in 4921ad71d06a532acf11148b877000a7986c52fa. https://github.com/csabahruska/proteaaudio/blob/master/CHANGELOG.md#080 I've uploaded it to hackage also.

[mgmeier]

Oh wow, that was fast :) Thank you Csaba!

[csabahruska]

What do you use this library for? I wonder if the API needs more newtypes? (i.e. Volume, Pitch, TimeOffset, SampleRate)

[mgmeier]

I'll give a short overview:

I'm working on a tracker-like player using proteaaudio, which basically translates a spreadsheet into playable data. I'm too busy (and untalented GUI-wise) to write a nice editor, so I just use a CSV for that. A later possibility is generating such a CSV along with PCM files from various digital tracker formats and so being able to use existing editors.

The spreadsheet should not be limited to tracker music though; the idea is to also use it as a "sound bank" for aggregating and triggering sound effects, as well as using pre-mixed sound files (e.g. OGGs), and having a simple and transparent way to manage and access them from your app.

That said, many of the more common tracker effects seem to be achievable via soundUpdate 'as is' (still trying out some of those).

The "proteaplayer" idea came up because im working on a SDL-based game in Haskell, and SDL audio was too low-level, so some research led me to proteaaudio. I instantly liked the level of abstraction it has, so I stuck with it.

When I'm a little further ahead, and if you're interested, I could give you some feedback about the API? What might be nice to have exposed as a newtype? What might feel clunky or might have some performance overhead? You can decide if and how it fits with the design goals of this package.

[csabahruska]

Sure! Please give feedback on the API.

The newtype wrappers could improve the readability of the code:

[mgmeier]

That's true... on the other hand it's also nice to be able to do Float arithmetic directly with all values, without wrapping/unwrapping/casting. For example, when you automate several parameters of a Sound ("channel") at once.

Sure I'm happy to get back to you with some more experience soon... I think I got your contacts still somewhere. We met in Berlin, with Andor, on a Lambdacube meetup some time ago. So, the Haskell world is small :)

[csabahruska]

Yes I remember. :)

[csabahruska]

Just open a new ticket for your API suggestions. I'll close this one.