Second counter accuracy

Mar 11, 2009 at 10:37pm

Second counter accuracy

Hi. I’m doing a project where i need realtime time-input from my system-clock. Right now i’m using a simple mxj-setup witch reads the SimpleDateFormat-object in java. Problem with this is that i have to bang the [mxj] for each second. After a while it gets a bit off time.

So i was wondering if there is an alternative to banging [mxj] or [date] (preferrably very accurate)?

- Peter

#42807
Mar 12, 2009 at 3:19am

[date] reports ticks with a precision of 1/60 seconds. If you bang it 60 times every second, is it enough for you? If you want more, you could use a line or line~.
Not sure I understand exactly your question though.
J-F.

#153240
Mar 12, 2009 at 7:37am

Okay, yeah, I was maybe a bit unclear.

The whole system is based on [metro 1000], but after a while it gets a bit sloppy. This [metro] is supposed to be in sync with a [sfplay~] that is looping a 30-sec sample. But after a couple of hours the two of them are not in sync any more.

#153241
Mar 12, 2009 at 8:23am
Myring wrote on Thu, 12 March 2009 08:37
The whole system is based on [metro 1000], but after a while it gets a bit sloppy. This [metro] is supposed to be in sync with a [sfplay~] that is looping a 30-sec sample. But after a couple of hours the two of them are not in sync any more.

If the loop is exactly 30s, you could use [sfplay~]‘s rightmost ouptut to resync the [metro].
Or, instead of [metro], you could use MSP objects like for instance [phasor~ 1]->[change~]->[==~ -1]->[edge~] to get a more accurate time base.

#153242
Mar 12, 2009 at 8:40am
Patrick Delges wrote on Thu, 12 March 2009 04:23

If the loop is exactly 30s, you could use [sfplay~]‘s rightmost ouptut to resync the [metro].
Or, instead of [metro], you could use MSP objects like for instance [phasor~ 1]->[change~]->[==~ -1]->[edge~] to get a more accurate time base.

Or perhaps combine the two ideas and forget metro and get your bangs from the timing signal coming from the right outlet of [sfplay~], but not exactly sure what you are trying to do with your patch, so maybe that is not what you are after.

#153243
Mar 12, 2009 at 9:11am

Ah, okay, yeah. The idea behind the project is to create a auditory clock. The listener is supposed to stand in a circle of 6 speakers. So instead of the traditional sec-hand there will be a sound moving around the listener, these are the 30-sec samples.

The idea of using the ‘bang when done playing’ sounds like a good idea!

#153244
Mar 12, 2009 at 1:30pm

You can get sample accurate metronomes from my object samm~.

http://www.sarc.qub.ac.uk/~elyon/LyonSoftware/MaxMSP/

Good luck,
Eric

#153245
Mar 12, 2009 at 3:41pm

Are you sure your overdrive is on (Options->DSP Status)?

#153246
Mar 12, 2009 at 8:27pm
Jean-Francois Charles wrote on Thu, 12 March 2009 09:41
Are you sure your overdrive is on (Options->DSP Status)?

Hm, ‘scheduler in overdrive’ is unchecked and so is ‘in audio interrupt’.
Are these parameters that change the priorities of processing Max vs MSP?

#153247
Mar 13, 2009 at 1:07am

Try with Overdrive Off means that the scheduler thread is not synchronized with the audio thread. With Overdrive On, you ask Max to synchronize the Scheduler thread with the audio one (DSP). That means that 1000ms in the scheduler must correspond to, say, 44100 samples treated by the DSP (depending on your current sampling rate). That means the scheduler is more precise, especially concerning long term operation. Even if the scheduler may be unresponsive because you ask too much, a long-time shift shouldn’t happen.
On the other hand, usually, you don’t want audio interrupt. That would enable the Scheduler to take priority over DSP (for instance heavy MIDI operations could generate a delay in DSP, meaning a “click” if you produce sound).
Let us know if Overdrive On is enough to solve your problem or not.
Jean-François.

#153248
Mar 13, 2009 at 3:43pm

Sorry to incessantly flog my external samm~, but the reason I wrote it is so you’d never have to worry about overdrive being on or off, or fiddle with any other performance tuning parameters. As long as the DACs are on, you have perfect sync, effectively forever. Your soundfiles won’t go out of sync like what you experienced with metro. Ever. It’s been argued that doing timing in the signal domain is overkill, but the CPU demand of a samm~ unit with several metronomes is just about zero. There are certainly other sample accurate solutions that can be cobbled together in MaxMSP, but I like the samm~ approach because it takes just one object to solve the problem.

Eric

#153249
Mar 15, 2009 at 8:10pm

Okay, yeah. I think i’m going to test how it works with overdrive on in my first testing. The only processing I do that is not MSP, is a implementation of the VPAB-argorithm and a java-xml parser. So I don’t think the processing will do much damage to the audio-flow. But of course, it has to be tested Smile

Thanks for all your input Smile

- Peter

#153250

You must be logged in to reply to this topic.