calc remaining time from position signal

[A Kern]

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

[dlpinkstah]

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

[A Kern]

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

[dlpinkstah]

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!

[A Kern]

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

[A Kern]

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

[VideoScratch]

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

[VideoScratch]

here's the right link



http://www.mspinky.com/phpBB2/viewtopic.php?t=344

[A Kern]

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