Can you decorate members with 'extern "C"' for .NET usage ?

[aybe]

(Sorry but that's the only place where I could post this message.)

Have little C++ knowledge but I need to use codegen from C#, currently working on a app. that will be on the web, for free. I tried to change "#define CODEGEN_API _declspec(dllexport)" to "extern "C" _decl .....), removed that from the main class since I really only need to call "codegen_file" and because of the inability to access C++ classes from non-C++ languages.

So here's the problem now : It does work but it displays a console each time I call the DLL.

Can you provide some directions on how to achieve this ?

Thanks a lot.

[alnesbit]

This is a good suggestion, thank you.

If I understand correctly, you are saying that you are able to interface to the codegen library from your application and that it returns the fingerprints correctly, but that you are getting a spurious console window on your desktop?

I am not up to date on .NET development and we don't yet officially support it as a platform for Echoprint to run on, but if you or anybody else is able to supply a patch then we will integrate it into a development or feature branch for further testing and possible inclusion into a future release of the codegen.

[aybe]

Yes, I don't know why the (blank) console appears, is it the way how ffmpeg is called ? I don't know. Ideally I would like to have only the fingerprinting methods in the DLL where as now there are explicit calls to ffmpeg. (I plan to fetch codegen using another API)

I have started another project next to 'codegen' to see if I can separate these concerns, build that as a DLL with C style exports, but without breaking 'codegen' at all.

When I have it done, I will submit a patch.

Thanks

[alnesbit]

Yes, ideally the audio file decoding would happen as an in-process sort of operation rather than calling an external utility but these would require deeper structural changes to the codegen to call the API methods and link everything together. This would have to be a medium-to-longer term goal for codegen development.

Your idea for a slight refactoring of codegen sounds great, and we would welcome a patch or pull request. Thank you.

[aybe]

I need to take the time to make it right and understand it as well; that's my first serious project in C++ by the way. There is just so much stuff to care of compared to C# and since I'm a newbie in C++, I already spent significant time reading documents; actually 90% of the time but I am confident in making it !

I made some progress yesterday night and going to look at it again this week-end.

[alnesbit]

Great! This would be a fantastic feature to have. Let us know if you need any help or have any questions.

[aybe]

Hello,

I could not solve this issue :

Error 2 error LNK2001: unresolved external symbol "declspec(dllimport) public: class std::basic_string<char,struct std::char_traits,class std::allocator > thiscall Codegen::getCodeString(void)" (_imp?getCodeString@Codegen@@QAE?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ) D:\codegen\codegenDLL\codegenDLL.obj codegenDLL (I checked that this method is inside the DLL, it is)

I think it's not finding std::string, I tried to reference msvcrtd.lib, msvcprtd.lib, added includes, namespace, etc ... nothing. In the beginning I returned the std::string but it in the end it is much easier to retrieve a string from a char* in C#. What I don't understand is that none that I tried is on the original project yet it is working, I think I forgot no project settings when I created my project, I checked all options pages ...

My current code : The DLL consists of only this code, it's probably the simplest/cleanest approach, I dropped all the src folder except main.cxx so the code is right on the DLL and there's no dependencies from codegen.sln

include "stdafx.h"

include "..\src\Codegen.h"

extern "C" _declspec(dllexport) int CreateCodegen(const float* pcm, unsigned int numSamples, int start_offset) { Codegen *pCodegen = new Codegen(pcm, numSamples, start_offset); return (int)pCodegen; }

extern "C" declspec(dllexport) char* GetCodeString(int instance) { Codegen* pCodegen = (Codegen) instance; char_ code = (char*) pCodegen->getCodeString().c_str(); // ERROR IS HERE return 0; }

(Note : code is not completely shown due to formatting by GIT, code is really a char*)

That's the only things I will ever need, the Base64 stuff I will do it in C#, basically it's done now. I think the original project should be split in two, a console project with main.cxx only, what would remove dependencies to ffmpeg from the fingerprinting part.

I use BASS.NET for grabbing audio, but it is a C library in the beginning, we could use that instead ? It has FLAC support, IIRC ffmpeg does not.

Thanks

[alnesbit]

I think the original project should be split in two, a console project with main.cxx only, what would remove dependencies to ffmpeg from the fingerprinting part.

A clearer separation between the fingerprinting library and the codegen application wrapper would be good, yes. However, even now, running the codegen using the library interface should not require ffmpeg to be present, as it expects the data to be passed to it already as PCM.

I use BASS.NET for grabbing audio, but it is a C library in the beginning, we could use that instead ? It has FLAC support, IIRC ffmpeg does not.

FFmpeg does support FLAC, you just have to make sure your version has this support compiled in.

[aybe]

Ok, I will take a deeper look at it.

---

Do you have any idea on how I can fix the problem I told you last time?

Thanks

[alnesbit]

I have never tried running the C++ library from C# before, so I am not sure what the cleanest solution is to this particular problem. A quick Google search, however, landed me at this page, which looks like it might have some helpful information: http://stackoverflow.com/questions/935664/possible-to-call-c-code-from-c

[aybe]

Actually it's not related to C#, it was about referencing std::string in the 'classic' DLL, since GetCodeString() returns that. I could change it in the main project to output char* but well ... not a good move. Will have a look at it and see if I can separate the console app. from the lib. itself ...

[aybe]

Hi,

I just fixed the error ! (it was a preprocessor field with the wrong name.) Important step will be to make multiple projects, will look at that later.

So the DLL now compiles, no change at all in the source !!

But, Currently Codegen is totally useless without an application for an end-user, I have small ideas about the subject but suggestions are really welcome,

Is there any place on where we can talk about this and anyone can see it ? I have a forum, I could host such stuff but there should be a link either in this repository or in the main website, so people can see it and send their ideas.

Thanks :-)))

[alnesbit]

Great! Does this mean that you have the codegen working from C# now?

The main public discussion forum for Echoprint is a Google Group at http://groups.google.com/group/echoprint?hl=en

We also host a couple of forums at http://developer.echonest.com/forums where people sometimes discuss ideas for applications.

[aybe]

I can make the analysis, but when I get the string code, it looks like an not initialized space in memory. Further tests closed the app. what means that it has tried to access a denied area in memory ... I did debug the DLL, as soon as it reaches the return value, that string seems to be cleaned from memory.

I'll post there see if someone can help,

Thanks

[aybe]

Got it now ! (really lol) I used strcpy to get the code back ... but more important, I forgot there was Enable Unmanaged Code, I enabled and it was much more convenient then. Previously I could either debug one or the other, not both at the same time ...

Now about separating ffmpeg calls from Codegen class : After some thinking, I will NOT change the main project, just upload the DLL solution, it's much simpler. Already spent a lot for simple things, and it has a lot of uncertainty, my initial thought was to convert codegen all to C#, it sounded too crazy for me, in the end I learnt how to create a native DLL which is not bad in itself ... BUT I also learnt that I will (hopefully) never learn MSVC++ but plain old one ... such mess is unbelievable, on the other side VS is the best IDE, been able to go from native to managed the usual way.

Will post to the group for features ideas on an app. I also have plans for a WP7 app. actually the capturing part is done, the web request remains to be done, UI also etc ...

Can you explain GIT ? do you have to authorize me or something like that ?

:->

[alnesbit]

Hello aybe, that is great news. Glad it's working OK now, and would be very interested to see how this all fits together.

Right, I don't think it would be necessary to separate out the calls to ffmpeg from the rest of the codegen library, as they are already pretty well separated already. Are you still having the problem with the console window popping up? A native DLL written in C++ does indeed sound like the best solution at this point in time, rather than porting it to C#, especially if it is not too difficult to wrap it up.

As for ideas for an application, two common use cases for audio fingerprinting are identifying unknown songs in large collections and deduplication of duplicate songs in large collections. Would you be running your own Echoprint server or using ours?

We wouldn't need to authorize you to use Git. You can simply clone our repo, do all your work there, commit your changes to your local repo, and then create a series of patches using git format-patch. Another way might be to fork our repo, do your work in the fork, then issue a pull request through GitHub. Best to read up at http://help.github.com/ about all this stuff.

[aybe]

No console popping out, Still need to clarify : • allocation, will see when I do batch/profiling • I think I will look at duplicates first since I have many back in the time I needed to carry them, will see the perfs then! • preferably not my own ... Been looking on it but still looking for a good distribution • I'll take a look at git

Envoyé à partir de mon Windows Phone

---

De : Andrew Nesbit Envoyé : 21/03/2012 22:30 À : Aybe Objet : Re: [echoprint-codegen] Can you decorate members with 'extern "C"' for .NET usage ? (#36)

Hello aybe, that is great news. Glad it's working OK now, and would be very interested to see how this all fits together.

Right, I don't think it would be necessary to separate out the calls to ffmpeg from the rest of the codegen library, as they are already pretty well separated already. Are you still having the problem with the console window popping up? A native DLL written in C++ does indeed sound like the best solution at this point in time, rather than porting it to C#, especially if it is not too difficult to wrap it up.

As for ideas for an application, two common use cases for audio fingerprinting are identifying unknown songs in large collections and deduplication of duplicate songs in large collections. Would you be running your own Echoprint server or using ours?

We wouldn't need to authorize you to use Git. You can simply clone our repo, do all your work there, commit your changes to your local repo, and then create a series of patches using git format-patch. Another way might be to fork our repo, do your work in the fork, then issue a pull request through GitHub. Best to read up at http://help.github.com/ about all this stuff.

---

Reply to this email directly or view it on GitHub: https://github.com/echonest/echoprint-codegen/issues/36#issuecomment-4627661

[aybe]

whoops I used my phone for last post ....

There are still some missing parts on my code : tags. If I can keep Taglib calls ok then, otherwise I will use BASS just as I did for providing 30s of audio. Will also start a small application to really test, I will need a database backing all this.

From your experience can you give some advices ? Do you think an XML db would be suited for 1000s of tracks ? What about tables ? etc ...

For your information : I am doing music for years, mixing especially, with years I ended up creating my own solution, from nothing to a professional-grade software, using external turntables with a custom timecode etc ... Now Echonest arrival in my life comes a little unexpected, I knew Discogs but not this one. Planned to work on Discogs but I found Echonest quite nice, though Discogs might have better results on obscure songs. I was also working on music information retrieval, it is just perfect, since it will save a lot of time for me. So hopefully, I'll be able to contribute back to the service, I have a lot of music to analyze coming from CDs and vinyls.

Ok i'll be back, sometimes next week :)

[aybe]

Hi !

I am starting a duplicates finder app. All is ok with Codegen DLL now ...