Hey everbody
is three a way to calculate the played time / remaining time ... just from the position info and the length of the current song.?
I know that the objects can output those values directly, but I'm using a javaUI which is not running via mxj (as I unfortunatly can't avoid crackling sounds in the audio this way), but use UDP messages for the communication.
In order not to send to many info this way, I hope just to send the two position signals and, whenever a new song gets loaded, its length to my javaUI and calc the time info in there.
Any ideas how to do this??
Cheers
Achim
calc remaining time from position signal
-
- Site Admin
- Posts:1093
- Joined:Mon Jun 07, 2004 9:17 pm
very interesting!
Hi Achim-
Your project sounds very intriguing. I have many questions:
1) Are you not using Max/MSP? It sounds like you may be using jMax? If you're using jMax, are the MsPinky externals compatible?
2) For the playback of your audio files, are you using either the MPFS~ or the MPTCFS~ object? If so, then I would not calculate the remaining file play time using the position signal. Instead use the "query remainder" or "query msec_remainder" messages to the object.
I look forward to hearing a more detailed description of your project.
thx-
DLP
Your project sounds very intriguing. I have many questions:
1) Are you not using Max/MSP? It sounds like you may be using jMax? If you're using jMax, are the MsPinky externals compatible?
2) For the playback of your audio files, are you using either the MPFS~ or the MPTCFS~ object? If so, then I would not calculate the remaining file play time using the position signal. Instead use the "query remainder" or "query msec_remainder" messages to the object.
I look forward to hearing a more detailed description of your project.
thx-
DLP
Hey dlpinkstah
1. no, I'm using max. Never tried jmax, so I dont know if externals are compatible.
2. I'm using MPFS~ , and yes, I could use "query remainder" and "query msec_remainder" to get the info, but then I would need to send this info as UDP messages
in addition to the position signal. This is what I want to avoid. I'd prefer to send as few info via UDP as possible. Hence I hope to calculate the remaining time
from tracklength and position. The next days I'll try OSC as an alternative to see if this is faster than the UDP stuff I do now. Maybe this will allow to send more
info between the JavaUI and the maxpatch. I'm using Maxlink by jesse kriss http://jklabs.net/maxlink/ for the UDP stuff.
Anyway, the reason for all this is that I want to have a nice, fullfeatured, rezisable UI for mspinky. So the last 6 months I started learning java and wrote a pretty
nice Swing UI, which supports database based song selection and searching. I did the development on a dual CPU machine, and had no problems
with performance. But when using it on a laptop, the swingUI (started via mxj) caused cracks and interuppts in the audio. I tried couple of tricks to preform the
cpu intensive calls in a low priority max thread, but this showed up to be really difficult, as then all ui updating in java has to be called from the event
dispatch thread. This made synchronizing to difficult for me. Often even bringing a swing Frame to the front caused cracking sounds in the audio.
Then I hoped I could just give the jvm a lower priority in the taskmanager. But the jvm started by max does not show up there. So the only way to get this is to
seperate both applications, start the javaUI as a seperate process and hope this will solve the problems. That's why I use maxlink, sending messages
both way via UDP. And of course I want to send as few info as possible, to minize CPU time.
If you have any other idea how to get this working from inside mxj, I would be more than happy.
The UDP stuff is actually my last hope to get this thing running, as I'm out of ideas.
Finally, here is a screenshots for you. Hope you guys like it
1. no, I'm using max. Never tried jmax, so I dont know if externals are compatible.
2. I'm using MPFS~ , and yes, I could use "query remainder" and "query msec_remainder" to get the info, but then I would need to send this info as UDP messages
in addition to the position signal. This is what I want to avoid. I'd prefer to send as few info via UDP as possible. Hence I hope to calculate the remaining time
from tracklength and position. The next days I'll try OSC as an alternative to see if this is faster than the UDP stuff I do now. Maybe this will allow to send more
info between the JavaUI and the maxpatch. I'm using Maxlink by jesse kriss http://jklabs.net/maxlink/ for the UDP stuff.
Anyway, the reason for all this is that I want to have a nice, fullfeatured, rezisable UI for mspinky. So the last 6 months I started learning java and wrote a pretty
nice Swing UI, which supports database based song selection and searching. I did the development on a dual CPU machine, and had no problems
with performance. But when using it on a laptop, the swingUI (started via mxj) caused cracks and interuppts in the audio. I tried couple of tricks to preform the
cpu intensive calls in a low priority max thread, but this showed up to be really difficult, as then all ui updating in java has to be called from the event
dispatch thread. This made synchronizing to difficult for me. Often even bringing a swing Frame to the front caused cracking sounds in the audio.
Then I hoped I could just give the jvm a lower priority in the taskmanager. But the jvm started by max does not show up there. So the only way to get this is to
seperate both applications, start the javaUI as a seperate process and hope this will solve the problems. That's why I use maxlink, sending messages
both way via UDP. And of course I want to send as few info as possible, to minize CPU time.
If you have any other idea how to get this working from inside mxj, I would be more than happy.
The UDP stuff is actually my last hope to get this thing running, as I'm out of ideas.
Finally, here is a screenshots for you. Hope you guys like it
-
- Site Admin
- Posts:1093
- Joined:Mon Jun 07, 2004 9:17 pm
just send the msec_time or file_time
Thank you for that post, Achim. I am very excited to see your developments!!
I would suggest you not bother to send the postion signal to your Java UI. Just send the output from MPFS~ that you get from either "query msec_time" or "query file_time". Then you can calculate the remaining time inside your Java UI.
For the record: The position signal from MsPinky is only tied in a rather loose sense to the actual playback time of the file. This is only logical because the position signal recorded on MsPinky vinyl is not "timecode". I have to stress that again: MS PINKY RECORDS DO NOT CONTAIN TIMECODE. They contain encoded values each of which corresponds to a certain position on the surface of the vinyl. When you use this to cue up a file, the mapping between position and file time is a bit flexible, and loose. So in general when dealing with audio file cueing I think it's best not to use the position signal for display purposes to the user because that could lead to confusion. Better just display the actual playback time of the file.. and the remaining time as you're doing.
Thanks again. Keep up the great work!
I would suggest you not bother to send the postion signal to your Java UI. Just send the output from MPFS~ that you get from either "query msec_time" or "query file_time". Then you can calculate the remaining time inside your Java UI.
For the record: The position signal from MsPinky is only tied in a rather loose sense to the actual playback time of the file. This is only logical because the position signal recorded on MsPinky vinyl is not "timecode". I have to stress that again: MS PINKY RECORDS DO NOT CONTAIN TIMECODE. They contain encoded values each of which corresponds to a certain position on the surface of the vinyl. When you use this to cue up a file, the mapping between position and file time is a bit flexible, and loose. So in general when dealing with audio file cueing I think it's best not to use the position signal for display purposes to the user because that could lead to confusion. Better just display the actual playback time of the file.. and the remaining time as you're doing.
Thanks again. Keep up the great work!
Hey pinkstah,
thanks for the reply
But don't you somehow use the "position" signal internally in MPFS to calc msec_time?
As I said, I don't wont to send too much info over UDP, and I need the position signal already to control the waveform scrolling.
That's why I thought I can get away with just using the position signal for time calculations.
This brings up an idea. Can I use msec_time instead of the position signal to control the scrolling of the waveform.
Till now I didn't do any waveform stuff, but in the future I hope to use your js code in java to make it work.
So, with your waveform code, is it possible to use msec_time to lookup the waveform "scroll position" ?
Thanks again
thanks for the reply
But don't you somehow use the "position" signal internally in MPFS to calc msec_time?
As I said, I don't wont to send too much info over UDP, and I need the position signal already to control the waveform scrolling.
That's why I thought I can get away with just using the position signal for time calculations.
This brings up an idea. Can I use msec_time instead of the position signal to control the scrolling of the waveform.
Till now I didn't do any waveform stuff, but in the future I hope to use your js code in java to make it work.
So, with your waveform code, is it possible to use msec_time to lookup the waveform "scroll position" ?
Thanks again
OK, I managed to communicate with my UI over OSC, and as I can package multiple messages in a OSC package,
it's not anymore important to limit the amount of info to send (With the maxlink library I used before only single messages were possible to send)
Thanks anyway for your help. Let's hope this new approach will help in getting rid of the crackling sounds I have.
Cheers
Achim
it's not anymore important to limit the amount of info to send (With the maxlink library I used before only single messages were possible to send)
Thanks anyway for your help. Let's hope this new approach will help in getting rid of the crackling sounds I have.
Cheers
Achim
-
- Posts:46
- Joined:Thu May 05, 2005 8:03 am
- Location:france
hi
hey !
have you succeed with your UI ?
is it running on PC or Mac ?
i'm back with my pinky pitch new feature proposition.
have a look at my new post and maybe you can help us...
http://www.mspinky.com/phpBB2/viewtopic.php?t=175
have you succeed with your UI ?
is it running on PC or Mac ?
i'm back with my pinky pitch new feature proposition.
have a look at my new post and maybe you can help us...
http://www.mspinky.com/phpBB2/viewtopic.php?t=175
...happyness is a warm slipmate...
-
- Posts:46
- Joined:Thu May 05, 2005 8:03 am
- Location:france
oups
...happyness is a warm slipmate...
Hey videoscratch,
Unfortunatly I had to pause this development. I sure hope to get back on to it some time, but I fear this will take some more time. Also, it's currently not in a working state, so I can't post anything
Once I find the time to clean things up, I can post the code here and anyone who wants to use it is free to do so.
But don't expect anything anytime soon
Sory
Achim
Unfortunatly I had to pause this development. I sure hope to get back on to it some time, but I fear this will take some more time. Also, it's currently not in a working state, so I can't post anything
Once I find the time to clean things up, I can post the code here and anyone who wants to use it is free to do so.
But don't expect anything anytime soon
Sory
Achim