Java wrapper for Ms Pinky!
Posted: Wed Apr 22, 2009 4:27 pm
Hello all,
I got kind of curious about using Java and the Ms Pinky Vinyl Tracking system, so I tried it out and managed to create a small wrapper class for the pinky functions. So if there are any Java programmers out there who would like to incorporate the functionalities of ms pinky, go to http://pinkywrapper.kotuha.be and have fun
It's far from perfect right now, still have a lot of things to read and learn but it does work at this moment. Only biggest problem is ASIO support in Java atm, but I know it is possible and I will figure it out sooner or later and make an update I just wanted to share the dll and java class so others might start using it to!
I do have a couple of questions though about the MPVT object:
1. Whenever I try to pass a sample buffer (left/right) with a array size bigger than 2048, the object seems to crash. I know that Java can easily handle arrays with a bigger size, so either the object just does not support it, or C++ doesn't ? My only C++ experience is the one I got while writing the wrapper dll, so it isn't much. Could anyone tell me what could be going on? Is there a maximum array size in this programming language, or will I have to take a closer look at how I pass the arrays between Java and the C++ dll? This is not really relevant to the pinky wrapper anymore, particularly now that Asio support in Java is a fact!
2. In the software specification PDF, it says the object will create a new measurement every 32 samples. But in the BinkyToy MFC example, I see that num_measurements is determined by dividing the buffer size by 64, not 32 ? And the size of the measurements arrays (gPowerVals, gPositionVals, gVelocityVals) is determined by dividing the buffersize by 128?
Using 32 samples per measurement returns velocity values which are correct for the first half, and then become smaller and smaller until they are all zero? Is there something important I am missing here, or have I misread something?
3. While the values I recieve from ProcessBuffer() seem to be correct (except that the first value of the arrays always returns 0.0 so that I get one less measurement then specified..), the values from the Query_SignalPower() and Query_Velocity() are always 0.0, unless I set the cutoff frequency lower or equal to -60dB.
Are there any specific reasons for these problems? Or does this mean there is still something important wrong in my own code? Please let me know
For what I needed it to, it works great; I can play an mp3 file and control it's playback speed and position with my pinky vinyl record. Although I still need to figure out a better way to keep track of the positions, sometimes I still miss a position change! Any tips on that maybe as well? I am currently just checking each positionValue with the previous one to see if there is a bigger change than usual (usual meaning the normal difference at the current playback velocity). I am comparing these differences with hardcoded numbers I got from reading the velocity & position values. But perhaps there is a more robust and statistical approach to this?
Thanks for any tips, I am looking forward to exploring more about this wrapper programming and building a better version
I got kind of curious about using Java and the Ms Pinky Vinyl Tracking system, so I tried it out and managed to create a small wrapper class for the pinky functions. So if there are any Java programmers out there who would like to incorporate the functionalities of ms pinky, go to http://pinkywrapper.kotuha.be and have fun
It's far from perfect right now, still have a lot of things to read and learn but it does work at this moment. Only biggest problem is ASIO support in Java atm, but I know it is possible and I will figure it out sooner or later and make an update I just wanted to share the dll and java class so others might start using it to!
I do have a couple of questions though about the MPVT object:
1. Whenever I try to pass a sample buffer (left/right) with a array size bigger than 2048, the object seems to crash. I know that Java can easily handle arrays with a bigger size, so either the object just does not support it, or C++ doesn't ? My only C++ experience is the one I got while writing the wrapper dll, so it isn't much. Could anyone tell me what could be going on? Is there a maximum array size in this programming language, or will I have to take a closer look at how I pass the arrays between Java and the C++ dll? This is not really relevant to the pinky wrapper anymore, particularly now that Asio support in Java is a fact!
2. In the software specification PDF, it says the object will create a new measurement every 32 samples. But in the BinkyToy MFC example, I see that num_measurements is determined by dividing the buffer size by 64, not 32 ? And the size of the measurements arrays (gPowerVals, gPositionVals, gVelocityVals) is determined by dividing the buffersize by 128?
Code: Select all
int buffsize = 4096;
buffsize = (buffsize>>7) + 1;
// result is 33, so divided by 128?
buffsize = 4096;
buffsize = (buffsize>>6) + 1;
// result is 65, so divided by 64?
3. While the values I recieve from ProcessBuffer() seem to be correct (except that the first value of the arrays always returns 0.0 so that I get one less measurement then specified..), the values from the Query_SignalPower() and Query_Velocity() are always 0.0, unless I set the cutoff frequency lower or equal to -60dB.
Are there any specific reasons for these problems? Or does this mean there is still something important wrong in my own code? Please let me know
For what I needed it to, it works great; I can play an mp3 file and control it's playback speed and position with my pinky vinyl record. Although I still need to figure out a better way to keep track of the positions, sometimes I still miss a position change! Any tips on that maybe as well? I am currently just checking each positionValue with the previous one to see if there is a bigger change than usual (usual meaning the normal difference at the current playback velocity). I am comparing these differences with hardcoded numbers I got from reading the velocity & position values. But perhaps there is a more robust and statistical approach to this?
Thanks for any tips, I am looking forward to exploring more about this wrapper programming and building a better version