Open up DSP architecture

[EliC]

It occurs to me that many of my recent and desperate requests could be handled with DSPs. Spoon, is there any chance you would open the DSPs up for outside development and release documentation on how they interact? I have a few people that may be able to help me with DSP development if it were open.

[trainee]

Re: Open up DSP architecture

While I suspect openning the dsp interface may end up being more work then supporting the DSPs directly... I would be in favor of this as well, since it would allow us to go after the specific configurations and options that many of us are looking for.

[tommyz]

Re: Open up DSP architecture

I vote for this too

TommyZ

[EliC]

Re: Open up DSP architecture

While I suspect openning the dsp interface may end up being more work then supporting the DSPs directly... I would be in favor of this as well, since it would allow us to go after the specific configurations and options that many of us are looking for.

It may well be but there are a number of feature requests that spoon seems uninterested in supporting, and this would allow many to be developed outside.

Spoon had previously opened up the DSP system, but no outside DSPs were created. I would argue, that since then R12 and R13 have attracted a different crowd that would be more likely to develop DSPs.

[sredmyer]

Re: Open up DSP architecture

I would also like very much to see a DSP SDK offered.

I realize that we can currently do some by simply calling the Run External DSP to call our own custom written app. However, a more full featured interface that exposed some of the core information (ie. CRC, AR CRC, rip results, etc.) or even offering two way interaction would be very useful.

Having this ability for the Batch Ripper would be a huge help in creating automation tools customized to a particular workflow.

[EliC]

Re: Open up DSP architecture

Spoon, are there significant barriers to opening the DSP architecture? With your focus on other development projects I really believe that some end users could truely advance the functionality through DSPs.

[Spoon]

Re: Open up DSP architecture

Done (but it is fairly technical):

http://forum.dbpoweramp.com/showthread.php?p=105445*blooper*post105445

[EliC]

Re: Open up DSP architecture

Amazing news and THANK YOU very very much.

I know I may be pushing my luck, but would you consider opensourcing some/all of the current DSPs to allow developers to see how you have designed them to work. I have some friends that code and would be willing to help me out with small changes I would like like altering the behavior of "move destination file on error" to move all songs in the album to a "bad rip" directory. Thanks again.

[biggles]

Re: Open up DSP architecture

this....is......awesome.

I'd love a revised Replaygain DSP that does not update all the album replaygain tags for all albums as the last step of a batch run, so that antivirus safeguards are not tripped by having a massive number of files modified in short a period of time. Perhaps write the album replaygain tags as each album is processed, or add in a delay during the last step.

I'll never need Foobar again if this change is made.


...and a DSP for creating COMMENT ITUNNORM and COMMENT ITUNSMPB in hex format that iTunes and iPods can read. And similar steps to improve compatibility with Apple products. This could hlep draw a huge number of quality-conscious but not techy rippers away from iTune's built-in (burst-mode-only) ripper. Hey, it's Christmas time, right?

[EliC]

Re: Open up DSP architecture

Gregory S. Chudov, developer of CueTools and CueTools DB has already indicated his intention to add support for CTDB:

http://www.hydrogenaudio.org/forums/index.php?showtopic=79882&view=findpost&p=733204

[EliC]

Re: Open up DSP architecture

Gregory S. Chudov, developer of CueTools and CueTools DB has already indicated his intention to add support for CTDB:
http://www.hydrogenaudio.org/forums/...dpost&p=733204

Update, I have spoken with Gregory. He had looked at the DSP interface and it was not clear to him how he would go about developing the CTDB DSP. Since he is not a dBpoweramp user he probably will not continue at this point.

[EliC]

Re: Open up DSP architecture

Gregory has developed a plug-in for EAC. I have spoken with a couple of developers interested in making DSPs, but after looking at it, they have all said that the information is unclear and does not appear to offer much access to functions of the software.

spoon, is there additional documentation that would be more helpful for other developers?

How about open-sourcing a few of the current DSPs as I have suggested before?

[Spoon]

Re: Open up DSP architecture

All our DSPs rely on our internal class system, which we cannot OS

[EliC]

Re: Open up DSP architecture

All our DSPs rely on our internal class system, which we cannot OS

Thanks for the response and clarification.