Myring

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)?

second-counter-accuracy

[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.

[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.


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.

Myring wrote on Thu, 12 March 2009 08:37The 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.


Patrick Delges wrote on Thu, 12 March 2009 04:23

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.

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.


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!

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

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

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

Jean-Francois Charles wrote on Thu, 12 March 2009 09:41

Hm, 'scheduler in overdrive' is unchecked and so is 'in audio interrupt'.

Are these parameters that change the priorities of processing Max vs MSP?

Jean-Francois Charles wrote on Thu, 12 March 2009 09:41Are 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?


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.

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.


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.

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

Second counter accuracy