Wasn't sure where you'd put the update so I downloaded the 0.9 version again but the error still occurs?
Using a different sample this time though - 16bit, 44.1Khz, mono WAV
chipmusic.org is an online community in respect and relation to chip music, art and its parallels.
You are not logged in. Please login or register.
ChipMusic.org / Forums / Posts by neilbaldwin
Wasn't sure where you'd put the update so I downloaded the 0.9 version again but the error still occurs?
Using a different sample this time though - 16bit, 44.1Khz, mono WAV
Good stuff man I'll give it a try later.
I got fail.
See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.
************** Exception Text **************
System.IO.DirectoryNotFoundException: Could not find a part of the path 'ssrc\~tmpx.wav'.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite)
at RJDMC.Form1.OpenWav(String FilePath)
at RJDMC.Form1.OpenWAVE_Event(Object sender, EventArgs e)
at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.ToolStrip.WndProc(Message& m)
at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
RJDMC
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Documents%20and%20Settings/Administrator/Desktop/RJDMCv0.9/RJDMC.exe
----------------------------------------
Microsoft.VisualBasic
Assembly Version: 8.0.0.0
Win32 Version: 8.0.50727.3053 (netfxsp.050727-3000)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/Microsoft.VisualBasic/8.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll
----------------------------------------
System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Runtime.Remoting
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Runtime.Remoting/2.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll
----------------------------------------
System.Core
Assembly Version: 3.5.0.0
Win32 Version: 3.5.30729.1 built by: SP
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Core/3.5.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.
For example:
<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>
When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.
Happens when I try to load a .WAV (16bit, mono)
Updates http://blog.ntrq.net/?p=412
I think the best suggestion so far would be to just have a key combo that would put PR8 into slave mode and the screen (and screen updates) would get turned off then the code can just sit in a background loop waiting for sync/triggers until you press another (same) key combo to kick it out of slave mode and back into the editor.
It would probably be safe to assume this would work but on the other hand it would be a shame as it would be so good to be able to still edit parameters in PR8 as it's playing.
I need to do some experimenting. Some things here can be ruled out immediately because either a) it's just not possible on a NES or b) it's just not possible because of how much processing time it takes to update PR8 (worst case).
Could do with a hardware heavyweight such as Batsly or blargg getting involved in this discussion.
Another video, this one is pretty sweet
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
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.
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?
neilbaldwin wrote:@low-gain: It would be cool if you could send me one and I can do some further testing. PM me if you want paying for it etc.
do you have any gear that runs sync24?
likewise... we'd have to figure out a port spec... i.e. which pins on the controller connector would be the clock line, start/stop line.
I was going to buy one of these (MIDI-syn24 box):
http://www.philrees.co.uk/products/sync-if.htm
So presumably I could go:
Computer/MIDI MTC/Clock ---> MIDI/syn24 Converter ---> your DIN/NES controller cable -> NES
Would that be right?
@low-gain: It would be cool if you could send me one and I can do some further testing. PM me if you want paying for it etc.
@low-gain
In order to do this, would I have to decouple the step sequencer from VBLANK altogether. My instinct says yes as each time the NES receives a pulse to advance, we could be waiting almost 1 frame before the actual signal is acknowledged and acted on. It might not be an issue though, I really can't tell.
Essentially, doing the button press way, you're not actually doing any synching at all - PR8 would essentially be turned into a kind-of arpeggiator MIDI device and the sync pulses would be just telling PR8 to play the next note.
I guess it could be designed so that there's:
+ 1 button which advances the step sequencer
+ 1 button to start/stop
+ 1 button to reset (start the song/pattern from the beginning)
but then it starts to get very specific to my application and perhaps not much use to others. That's the nature of the beast though I guess.
Shiru's explanation is spot on.
This is why in NTRQ (and Pulsar) I display a BPM figure that the playback is running at instead of allowing you to specify a BPM. This value is pre-calculated and stored inside the code so if NTRQ displays 128.6 BPM then it should be running at exactly that. I did some test using Ableton Live (record a few bars from Pulsar in Live then see what Live computes the tempo to be) and it seemed to be consistent with my calculations.
It's not ideal though.
Of course, it's perfectly possible (to a certain extent) decouple the playback from the frame rate and just play the music back based on a simple counter but this approach is not really compatible with a tool such as NTRQ/Pulsar which requires graphical updates (graphical updates ABSOLUTELY must be in sync with the frame rate because you only have a small window of opportunity at the start of each refresh frame in which to write to the 'screen'). The reason I say this is that if you just wanted to display a static screen, you should be able to have much more fine control over the refresh speed of your audio.
I've been doing some experimenting with PR8. I've made it so that instead of a counter to advance the step sequencer, it can sit and wait for a button press on controller 2.
I'm just thinking out loud here but wouldn't it be pretty simple to rig up a MIDI->electronic pulse cable and then in your external sequencer, assign a MIDI control to send each time you'd like PR8's sequencer to advance a step and it should just work?
I guess you'd have to create a "dummy" track in your song that just sent out constant MIDI messages to keep PR8 moving but that wouldn't be too much trouble would it? You'd also have the advantage of it staying perfectly in sync with your tempo changes.
Not sure about the difference in resolution. I'm still only polling the second controller port @ 60hz but unless you've got an insanely fast track it should keep up shouldn't it?
Just want to use this thread as a place for ideas as I really need to get this external sync lark sorted, for Pulsar too.
ChipMusic.org / Forums / Posts by neilbaldwin