neilbaldwin
Offline
WOW MAN!
tRasH cAn maN wrote:

While Sync24 is all retro and cool, not arguing there, why not start with standard midi beat clock sync which 95% of all the users would probably use anyways. It wouldn't be hard making an arduino based sync device that could handle inputing and outputting both. And LSDj or nanoloop sync for that matter.

I guess, in essence the two methods are the same. If that's the case then I agree it would be better to go with MIDI Beat Clock as it's more ubiquitous than Sync24.

Low-gain?

Lazerbeat
Offline
Tokyo, Japan

I know nothing about the technical side but midi beat clock sounds better to me as a user.

spriteful
Offline
Vancouver, BC

Definitely the final design should include a way to get Midi Clock input; however if the DIN Sync cable is cheap and easy, it might still be the quicker way to test the synchronization concept.

If the final design was modular with two stages (midi->voltage) and (24ppq->4ppq), then perhaps the 2nd stage would be quite cheap and people who only need Din Sync input or already have a midi->din sync converter could just pay for that part.

I like the point about building in lsdj/nanoloop sync; it's an appealing concept to have a 'Sync anything to the NES' box.

I haven't tried the arduinoboy... does anyone know off the top of their head the basic sync approach used there and how well it works?

@nickmaynard-- Yeah it's good to consider how lag times will operate and how to compensate for it. To clarify, in that quote I wasn't talking about lag, but rather about jitter= random timing variation from beat to beat.

nordloef
Offline
sweden
tRasH cAn maN wrote:

While Sync24 is all retro and cool, not arguing there, why not start with standard midi beat clock sync which 95% of all the users would probably use anyways. It wouldn't be hard making an arduino based sync device that could handle inputing and outputting both. And LSDj or nanoloop sync for that matter.

^ This and forever this.

low-gain
Offline
Milwaukee, Wisconsin USA

i wasn't recommending sync24 because it's retro... it's reliable and very much still used by a lot of electronic musicians.
It's a starting point to do a proof of concept w/ analog clock since one can easily make a 555 clock to proof it if responds as it should.
From there the timing can easily be switched over to midi clock if so desired. but i think having both analog clock and midi clock will be a must
in the end.

Trash80
Offline
Los Angeles
spriteful wrote:

(PC MIDI Interface Jitter can easily be 10ms) + (midi-pulse-converter Jitter if any) + (+/- half of 1/60 s jitter, is what about 8ms) = ??

[technical rant]
PC Midi shouldnt have jitter, Some audio / midi programs add delay to the midi out to match the latency of the audio signal. Most of the nice apps have options for changing this- Like ableton live.

Midi should have a delay anywhere from 0 to 3-5 ms maybe. Being that its 31250bps and 10 bits per byte. (start bit + 8 bits + stop bit) a sync message is just 1 byte. If all you are sending is clock tick, the latency would be 3 ticks per ms. This of course doesn't account for computer driver & software latency, but I usually get around 2ms. - Yes I actually check this when I'm programming with sync/midi data.
[/technical rant]


Anyway, 120bpm breakdown:
- 24ppq: 48hz .... (120*24) / 60
- 32nd notes: 16hz .... (120 * 8) / 60
- 16th notes: 8hz .... (120 * 4) / 60
- 8th notes: 4hz .... (120 * 2) / 60

Anyway I guarantee you that without a proper interrupt or something triggering in time, the timing will be wonky / loose. At least with my experience- Maybe I suck. 

As far as sync24/midi sync etc, its all the same really- just need a function to trigger the joypad or whatever input, in the NES software, and from there we can add quadaflank usb super sync 4000.

Neil: The easiest solution for testing would be to get a Arduino, port manipulation & microcontroller flashing is fast and simple using their framework / ide, which makes for a faster prototyping / testing environment. *ITS SUPER EASY*

Trash80
Offline
Los Angeles
low-gain wrote:

i wasn't recommending sync24 because it's retro... it's reliable and very much still used by a lot of electronic musicians.
It's a starting point to do a proof of concept w/ analog clock since one can easily make a 555 clock to proof it if responds as it should.
From there the timing can easily be switched over to midi clock if so desired. but i think having both analog clock and midi clock will be a must
in the end.

Input is up to the hardware that connects to the port. So to me it's a nonissue. it's really about getting a accurate timing input. If we are using the joypad at 60hz, the only reliable timing would be having a timing from the sequencer at a rate devisable of 60hz- at least on paper- unless I'm missing something.

neilbaldwin
Offline
WOW MAN!

Hmmm. This is what I suspected.

I'm fairly sure you can't read the control ports arbitrarily - I think it's similar to doing DMA to the screen in that you have a particular window of opportunity per vertical blank in which to access the ports.

I'll check though, I'm not 100% certain.

tRasH cAn maN
Offline

It might not be optimum, but if you disable the screen altogether during synced playback you should be able to read the port regardless of vblank and the 60Hz., no?

neilbaldwin
Offline
WOW MAN!
tRasH cAn maN wrote:

It might not be optimum, but if you disable the screen altogether during synced playback you should be able to read the port regardless of vblank and the 60Hz., no?

That was precisely my line of thinking. It's going to take some serious juggling to get that working. It's all complicated by the fact that I'm running the synthesis at 120hz (twice per frame) and the step sequencer at 60hz. Why do I do this to myself? LOL

nitro2k01
Offline
Sweeeeeeden

My take on this is this: Hook up a damned microcontroller that acts as a middle man. An Arduino, just for blog cred, perhaps? The microcontroller then waits for sync pulses from MIDI or Sync24 or whatever you want. As soon as it receives a pulse, it increments a counter. When a clock is received by the NES, the counter is again decremented. Typically the counter will never get above 1 or 2 or so, as we'll see.

On the NES side, the CPU can do one of two things:
1) Deal with audio. (Be busy)
2) Constantly poll for new data. If the CPU is idle, nothing in the whole world stops it from polling data as fast as it can, not just once every 60 Hz frame. As soon as it receives a pulse, it gets busy, and then returns to waiting for a pulse. The $4016/17 registers are essentially just two-way bitbanging.

And if you really hate microcontrollers and MIDI, this idea should be realizable with only some 74hc logic, assuming the timing input is sync24.

spriteful
Offline
Vancouver, BC

@trash80--
I agree with your way of thinking that quantizing incoming beats to intervals of 1/60 s may be on the sloppy side, and that's probably the crucial question to ask. I was trying to say the same thing, just phrased in terms of jitter.

As a minor point, midi output from a PC does in fact exhibit jitter, and usb ones are often the worst kind-
See e.g.
this forum thread

offtopic:  Sodium Sonet is a killer track, that's you right?  smile

Last edited by spriteful (Dec 6, 2010 10:02 pm)

boomlinde
Offline
Sweden

nitro2k01 has got the best idea so far, but if the irq takes too long it will still be jittery - probably not close to as much as in the original approach, though (16 ms jitter?).

tRasH cAn maN
Offline

But isn't Nitro's idea just to ensure you don't drift in sync? It won't help for any jitter or wonky sync. If the port can't throw an interrupt you're still a slave under the 60Hz clock.

boomlinde
Offline
Sweden
tRasH cAn maN wrote:

But isn't Nitro's idea just to ensure you don't drift in sync? It won't help for any jitter or wonky sync. If the port can't throw an interrupt you're still a slave under the 60Hz clock.

Yeah, you're right, as long as the player/synth is interrupt driven one will have to deal with 1/60 s jitter, but my idea is that the player/synthesis tick routine could be called while polling the joypad port outside the interrupt whenever external sync is enabled, leaving only the interface (screen drawing, other joypad handling) code in the interrupt.

Then, let's say that the interface code in the interrupt takes 1/4 of a frame (in raster time) - then it's down to a much more acceptable ~4 ms jitter.

EDIT: and as Neil mentioned, having separate rates for the sequencer and for synthesis complicates this further tongue

Also

I'm fairly sure you can't read the control ports arbitrarily

sad

Last edited by boomlinde (Dec 6, 2010 10:26 pm)

spriteful
Offline
Vancouver, BC

So, the graphics interrupt the audio rather than vice-versa?

Sounds clever.
But would it cause problems if the audio routine was interrupted between APU register writes... could cause timbral inconsistency? Or am I talking nonsense?

If the approach did work, maybe there could be a 'low-detail graphics' mode for live & synced play.


EDIT: oops, I see by your edit that the suggestion was not a way around the 'can't just read ports whenever' problem.

Last edited by spriteful (Dec 6, 2010 10:41 pm)