Forums - All Posts - The Amigans website

Forum Index

Board index » All Posts (sierratu)

Bottom

sierratu

Re: Enhancer 2 DataType.library issue

Posted on: 2021/4/21 9:17 #1

Just popping in

@ktadd

There were a couple of small changes previously that resulted in this situation coming about where it returns the wrong error code. I discovered this a few days ago while patching up some other issues and new version(s) of the library and datatype(s) should be released soon via the normal channels.

Apologies for the inconvenience.

Topic | Forum

sierratu

Re: Change datatype volume

Posted on: 2017/9/9 11:47 #2

Just popping in

@xenic

For the record, the A-Eon implementations all route to the sound.datatype to control volume, the subclasses do very little other than process the data source to pass it up the chain. If you're saying the volume changes don't work on these, let me know.

I cannot vouch for the OS supplied dt classes. I do know that the aiff/8svx didn't interact with the sound data type as expected and had to account for it to "make it work".

Topic | Forum

sierratu

Re: Enhancer sound.datatype pause/resume

Posted on: 2017/9/9 11:40 #3

Just popping in

@xenic

Quote:

As I mentioned in your "Change datatype volume" topic, when I switched to the OS4 sound.datatype, I wasn't getting any pause at all. I might retest all this tomorrow to see if I tested correctly

I don't believe the OS data type supports anything other than play and stop, so you might never get it working.

I'll investigate the jitter. I got this early on in development, but thought I'd resolved it - I've not had any issue for a while, but that doesn't mean I've not just been lucky.

Topic | Forum

sierratu

Re: Enhancer Bug thread

Posted on: 2017/9/9 11:33 #4

Just popping in

@Hans et al
Quote:

I know you did, and that example code really needs an update (it's a wiki...). Clearly someone copied code from somewhere else onto the wiki.

Nevertheless, the Autodocs (i.e., the specification) state that you shouldn't rely on the sound data being there. Unfortunately, the lack of streaming datatypes meant that nobody caught the error in the example code... until now.

This was my general response to Matthew when this discussion kicked off. The quoted example that the problem stems from is a naïve example - if followed verbatim you're only playing mono samples, no? Despite the possible presence of another channel or ten. Not saying it's wrong - just it's a very simple example that discounts a number of scenarios. It's also the case that if a continuous mode dt was set on OS3.9 components, the code would fail, so to be clear, this isn't a "bug" with the A-Eon implementation.

Quote:

Now, so many people have copied that example that we're better off adding a workaround to the datatype (and preferably updating the specification too).

The general solution proposed in this instance for the A-Eon data type was be to use a simple check for and loop/call to SDTM_FETCH to read the data - streaming mode or no. But, the response received was that this meant changes to the application which was undesirable (paraphrasing).

I'm looking to see how much effort and duplication it will be "fix" the subclasses to allow for non-streaming mode and sample retrieval. Might take me a while as time is at a premium right now.

Topic | Forum

Top