Hi Daniel, I saw some code in EngineController when I cloned the repository. The problem with your approach is that the path of AudioDataOutput will be always active. ADO use the CPU to manage and fill some QVector<short>. I coded AudioDataCenter to activate the AudioDataOutput path only when there is some module of Amarok that require it. And deactivate it when the last client is unregistered. Maybe a better approach could be to create EngineController::registerDataClient(AudioDataClient* c); EngineController::unregisterDataClient(audioDataClient* c);
instead of my approach: AudioDataCenter *EngineController::audioDataCenter(); AudioDataCenter::add(AudioDataClient* c); AudioDataCenter::remove(AudioDataClient* c); About visualM: I am totally with you about the applet approach. It was only an example. Maybe I should divide my patch in an AudioDataCenter Patch and a visualM applet patch. What do u think ? Alex On Sat, Aug 13, 2011 at 2:28 PM, Daniel Dewald <[email protected]>wrote: > Hi Alex, > > As I said my comment wasn't meant for you directly but more an urge I felt > to > bring this problem to greater attention as you are not the first (an will > most > likely not be the last) in this situation.. I just hate to see work wasted > all > the time (be it will be your work or the work of others). > > As for the audioDataOutput: That specific Problem was already "solved" by > me by > using signals and slots (then EgineController just had a signal for audio > data > which every class could connect to) a long time ago. However I didn't push > my > changes as the backends where far from ready at the time (and apart from > gst > still are) and some even crashed (xine which is now deprecated). > > Concerning your patch: The biggest problems I can see is that you have > visualization specific code (the visualM stuff) in the engine controller. I > haven't done a lot of work lately but I'd say it doesn't belong there as > the > engine controller is meant for phonon stuff only afaik. > > Also in my opinion (and I cant stress enough that it might very well not be > the opinion of the other devs) as amarok tries to advertise modularity > visualization should be done in an applet. > > As I said a lot of this Questions / Problems could have been answered / > avoided if you had asked. > > Greezt > > Daniel > > P.S. I hope someone more clear minded about this then me will comment ;o). > I'd > love to here the opinion of the other devs. > > On Friday, 12. August 2011 16:16:33 Alessandro Siniscalchi wrote: > > Hi Daniel, > > mmm ... ok. > > > > No personal pissings here. > > > > However my patch ,maybe, is more interesting for the AudioDataCenter > class. > > The visualM stuff is very intrusive ... and it was only an example to how > to > > use AudioDataCenter. > > > > I hope that the guy of vsxu could take some advange from my code, I mean > ... > > vsxu is very nice. > > > > A. > > > > On Fri, Aug 12, 2011 at 3:47 PM, Daniel Dewald > > > > <[email protected]>wrote: > > > Hey Alex,**** > > > > > > ** ** > > > > > > First of all nice to have you on board. So please don’t take my words > > > the > > > wrong way and don’t take them personal. However some other person was > > > also already working on a very similar solution using vsxu. If you had > > > read the mailing list or ASKED in the IRC Channel a lot of this work > > > could have been SHARED. I also worked on visualization for a while but > > > canceled my project because a lot of work on another feature was wasted > > > because of (now obvious) miscommunication problems. I think its > > > wonderful that new people are joining the Amarok team. But I kind of > > > getting really annoyed by the way they do it. When I first wanted to > > > contribute stuff to Amarok I asked in the IRC channel what I could do > > > and if no one else was working on that stuff (I’m still doing that > > > before beginning on a new feature). I find that only to be a polite > > > thing to do. Just throwing code at a project without caring what other > > > people might be working on is just rude. Be it as it may what is > > > pissing me of the most about it is how the community is (not) handling > > > this problem. It’s just ignored and code is chosen randomly and pushed > > > randomly no matter who was following “protocol” und who was just > > > storming in. As a matter of facts most of the times people who > > > carefully are holding back their code for bug fixing and present it > > > later are left behind while other people who just throw half bred code > > > at the project get their code pushed in immediately. In my opinion > > > people who are that rude should not get rewarded. **** > > > > > > ** ** > > > > > > Now as I said Alex this has only partly to do with your patch and has > > > been observed by me before. So don’t feel to pissed about my mail. I > > > just though as I seem to be the only one who cares I might bring it up. > > > It’s not my code that gets wasted this time so I shouldn’t care. But I > > > feel bad for the poor soul who got his work crushed this time as I > > > know how it feels.**** > > > > > > ** ** > > > > > > Greetz**** > > > > > > ** ** > > > > > > Daniel**** > > > > > > ** ** > > > > > > *From:* [email protected] > > > [mailto:[email protected]] *On Behalf Of *Alessandro > > > Siniscalchi > > > *Sent:* Donnerstag, 11. August 2011 11:01 > > > *To:* [email protected] > > > *Subject:* Visualization in Amarok**** > > > > > > ** ** > > > > > > Hi all,**** > > > > > > I just finished a patch that add the Visualization to amarok.**** > > > > > > ** ** > > > > > > https://git.reviewboard.kde.org/r/102277/**** > > > > > > ** ** > > > > > > As you can see there are 2 new modules:**** > > > > > > ** ** > > > > > > - audiodatacenter: it manage all the modules that need raw data**** > > > > > > ** ** > > > > > > - visualm: it uses audiodatacenter to register and receive data and > send > > > it to projectM-qt mainWindow.**** > > > > > > ** ** > > > > > > First ... I'd like to know what do u think about.**** > > > > > > ** ** > > > > > > Then ... I'd like to make visualm optional. Which is the way ?**** > > > > > > ** ** > > > > > > Cheers**** > > > > > > Alex**** > > > > > > _______________________________________________ > > > Amarok-devel mailing list > > > [email protected] > > > https://mail.kde.org/mailman/listinfo/amarok-devel > > -- > Daniel Dewald B.Sc. > Im Ginselt 8 > 66709 Weiskirchen > https://www.time-shift.de/ > > Zertifikat: > https://www.time-shift.de/Certificates/ > _______________________________________________ > Amarok-devel mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/amarok-devel > >
_______________________________________________ Amarok-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/amarok-devel
