yogi
Offline
Jelly Stone park, MD USA
m00dawg wrote:

Aha ok. Mostly makes sense (re the BPM) but I think I'll have to try it out and see to really know how it will affect things in practice but now I see what you're referring to.

Major changes to the NSF's tempo will mostly affect how a triplet or vibrato will sound, they'll be slower or faster, like changing the speed on a turntable (without pitch shift).
One workaround idea could be a second clock that free runs at or about 150 pulse rate for the NES but also syncs, in a very broad way, to the Midi master clock. You would write your NES track with it's internal BPM close to the song's BPM so it's 'what you hear is what you get'. Playback is controlled by the secondary clock's BPM but syncs to the Master Midi Clock every ~2, 4 or 8 bars (?) then adjust the Second Clock (small shifts) as needed to get the best timing.
This could all be in the uC, just a timer routine that's adjusted/locked to the incoming Midi Clock.

m00dawg wrote:

If the input/output trick works on Arduino there probably isn't much worry to do any other shenanigans so I think I'll try that first since I have all the stuff I need to get it going I think and I can go from there. Since this would be for stage and studio, I'll want to built something that is hardy enough. On that note, it sounds like MCTRL is doing very similar things so I'm guessing it would be useful for controlling FamiSlayer if I wanted to buy over build?

MCTRL is based on a Highly Liquid Midi board and is programmable but I think it responds to Note On/Off messages and not sure if it does Midi Clock messages.
So in your user case; you would have to use one of the tracks in your DAW to send the Note message timing, a Click track smile This may be more flexible to handle the issues; just come up with a note pattern that sends 150 'note ticks'
each Min of your song regardless of it's tempo. Does this sound more flexible to you? Because as I'm writing, it kind of seems like a really good way to control the NES, hummm.

m00dawg wrote:

By the way, thanks again! I've been wanting to do this for years now and the detail and time taken to explain all this is much appreciated!

No problem, Been wanting this sort of setup also, since I first heard about MidiNES in '01 or 02. That didn't workout too well for me, but lately there are a lot of great projects that pull this all together. Lucky Us smile
Yogi

DSC
Offline
yogi wrote:

MCTRL is based on a Highly Liquid Midi board and is programmable but I think it responds to Note On/Off messages and not sure if it does Midi Clock messages.
So in your user case; you would have to use one of the tracks in your DAW to send the Note message timing, a Click track smile This may be more flexible to handle the issues; just come up with a note pattern that sends 150 'note ticks'
each Min of your song regardless of it's tempo. Does this sound more flexible to you? Because as I'm writing, it kind of seems like a really good way to control the NES, hummm.


Yep, this way when the NES wants to use its own clock and drift off, you can keep it exactly where you want it.  This also allows for affects too as you can purposely slow and speed up timing when you want.  Neil Baldwin has made a special version of PR8 just for MCTRL. 

The other features he added using the second gamepad. By plugging in the MCTRL into the second port you can:

1)Send a midi note to advance the step's one at a time based on the midi note you send.
2)Advance to the next pattern immediately.
3)Advance to the next pattern, but wait till current pattern is finished.
4)Reset back to step one immediately.
5)Go back to the last pattern immediately.
6)Go back to the last pattern, but wait till current pattern is finished.

This makes it easy to sync and perform verbatim to your DAW.  If Pulsar is more of interest, I imagine Neil could also make these features available.

yogi
Offline
Jelly Stone park, MD USA

Thanks DSC!! Great info.
I've been playing with sync ideas for a bit and had headed down the Beat Clock path but am re thinking it now. The sync code I've been working on so far is based on FamiSlayer but I'm a little up in the air as to the selection of triggers and controller standards in a midi setting.

I don't want to encroach on MCTRL, it looks to be a solid, well built device. But before I finish off the code i've been working on I got to ask you if you can share any info on the button assignments and functions. I guess it's flexible with MCTRL's 'learn',  to work with any button usage; but I'd like to use the same assignments chosen for PR8, rather then create yet another control scheme.
yogi

DSC
Offline

Sure.  When I started the MCTRL project I started down the Arduino path, kinda like uXe and had some reasonable success.  I am glad uXe has released his solution too!  But I had worked with John at HighlyLiquid before with his Speak & Read midi kits and really liked the way he executed that, so I did more research into his PCB's and the software that was built for them.  This is primarily the reason I went with them in the end.  MAC & Windows platform support was great as I mostly use PC's, but I know a lot of people who use MAC's. Also he carries these in stock, so if anyone wanted to put their own together than they could by purchasing the pcb and build their own if they wanted to save money.  So the software like I mentioned is the reason I went with the HighlyLiquid pcb.  Here is a couple of screenshots.


You can see by the drop down that you can assign a wide variety of midi types, so if you wanted to use one midi channel and send various CC messages, you could.

Every MCTRL also has a label underneath that looks like this.  You can easily open up the box and flip the dip switches to change the midi channel.  You also can flip connector sides so you can have the cables coming out of the side that is most convenient with your setup.

I really tried to think of everything I could that would be the ultimate MIDI tool for the NES.
I know the MCTRL will seem expensive to some, but there is a lot of work in these boxes, and I do all of the fabrication myself, in house, to try and make them as affordable as possible.  Please feel free to ask any questions.  I love including PR8 into my sets big_smile

yogi
Offline
Jelly Stone park, MD USA

Excellent! Quality product and worth the cost. Full understand the design choices; looks like it would stand up to the the demands of being on the road well.

So did I understand from the screen shots that it's configured via a SysEx message? That would work well with multiple cartridges and different control configurations, could embed the cart's configuration within the midi file.
yogi

DSC
Offline

Thank you,
Yep, SysEx is how it communicates.  That was one thing that was kinda of a drawback considering Arduino would have USB, but in the end multi OS platforms and features seem to be more desirable.  Oh, and the order of buttons was 'Up' 'Down' 'Left' 'Right' 'Select' 'Start' 'B' and 'A'.  In my own setup I use a Cirklon to stay in perfect unison with my live setup.  This way I don't even use a DAW or computer in my live rig.

yogi
Offline
Jelly Stone park, MD USA
DSC wrote:

Thank you,
Yep, SysEx is how it communicates.  That was one thing that was kinda of a drawback considering Arduino would have USB, but in the end multi OS platforms and features seem to be more desirable.

Cool, like'n that. Would streamline switching carts, but with the learn function it's easy enough. I'm ok with straight Midi on kit; USB to Midi interfaces are common and universal. In some way USB midi is kind of limiting, hard o find a sequencer that functions as a USB host.

 

DSC wrote:

Oh, and the order of buttons was 'Up' 'Down' 'Left' 'Right' 'Select' 'Start' 'B' and 'A'.  In my own setup I use a Cirklon to stay in perfect unison with my live setup.  This way I don't even use a DAW or computer in my live rig.

That looks awesome!

Looking through your site; Sega(?)   Hmmmm...will have to keep an eye on it smile
Yogi

m00dawg
Offline
Texas

I am eyeing MCTRL actually, along with Pulsar. The reason I liked going the FamiSlayer route is I find FamiTracker a lot easier to work with than, say, LSDJ. The downside is I don't have sync when composing songs like I do using LSDJ, so composing is a bit non-linear when working with other synths.

On that note, though, the idea of using a sort of BPM track to send to the NES seems workable. If that works, though, it seems like sending the MIDI clock through and having a bit of code on the uC could do the same affect but without having to toss that in every-time? I've had to do the sync track for our drum machine (which is really just a glorified click for us) and it's a bit annoying to setup over just having a clock.

So, since we're now including MCTRL in the discussion - how easy of a modification might that be (DIY or otherwise)? One of the reasons for going the Arduino route was really just to reduce the number of stuff we have, particularly during a live show. If one box can sync both the GB and NES, it would be really convenient. But otherwise, MCTRL is there, works, I could look at using Pulsar with it - so the only gap is the discussion on syncing with a MIDI clock using FamiSlayer or some other NSF player, based upon some of the previous discussions in this thread?

I guess long story short, it sounds like going from MIDI Clock to NES requires either some caveats / things to be mindful of, or uC support to make things function like they would with LSDJ or other MIDI clock-aware devices?

yogi
Offline
Jelly Stone park, MD USA
m00dawg wrote:

I am eyeing MCTRL actually, along with Pulsar. The reason I liked going the FamiSlayer route is I find FamiTracker a lot easier to work with than, say, LSDJ. The downside is I don't have sync when composing songs like I do using LSDJ, so composing is a bit non-linear when working with other synths.

Yea, composing on a native tracker is fun, but cross platform tools have a better workflow, imo. Full key board and such.
ATM only PR8 has been extended for sync control; I would love to see Pulsar with sync as well! ( Hey Neil? Hint Hint)

m00dawg wrote:

On that note, though, the idea of using a sort of BPM track to send to the NES seems workable. If that works, though, it seems like sending the MIDI clock through and having a bit of code on the uC could do the same affect but without having to toss that in every-time? I've had to do the sync track for our drum machine (which is really just a glorified click for us) and it's a bit annoying to setup over just having a clock.

A Midi Clock to Sync converter is the easiest user solution but requires some firmware development time. With just a 1:1, Clock to Sync24, conversion it may be useable for allot of tempo signatures; the down side is using FamiTracker to compose. A track will sound different during playback then when you compose it. But you may be able compensate with FamiTracker's settings.

m00dawg wrote:

So, since we're now including MCTRL in the discussion - how easy of a modification might that be (DIY or otherwise)? One of the reasons for going the Arduino route was really just to reduce the number of stuff we have, particularly during a live show. If one box can sync both the GB and NES, it would be really convenient. But otherwise, MCTRL is there, works, I could look at using Pulsar with it - so the only gap is the discussion on syncing with a MIDI clock using FamiSlayer or some other NSF player, based upon some of the previous discussions in this thread?

Not sure on single Arduino control option, don't know enough about the ArduinoBoy code. Lots of IFs
MCTRL should work with FamiSlayer but again you'r back to a timing track (which you would need with PR8 also). The plus is you have fine grain control to adjust (via the track) without disturbing the other tracks' tempo, but this is also an extra burden.

m00dawg wrote:

I guess long story short, it sounds like going from MIDI Clock to NES requires either some caveats / things to be mindful of, or uC support to make things function like they would with LSDJ or other MIDI clock-aware devices?

No perfect solution ATM. If I had the skills, the best would be a sync-able NSF driver. Guess that is possible, the FamiTracker source code is open, if someone has a mind to change it.
Yogi

yogi
Offline
Jelly Stone park, MD USA

Been doing some searches, found this http://famitracker.com/wiki/index.php?t … _and_tempo

FT Wiki wrote:

Another option is to use a user-defined clock speed, but then you have to modify the calculations above to determine which tempos are acceptable under which clock speeds. One drawback of this method, though, is that few NSF players support custom clock speeds, so NSF export is compromised.

This may overcome the limitations we've been discussing (?)
yogi

EDIT: Just did some basic tests in FT.
Under "Tracker" tab, "Engine Speed" set to "Custom"  to adjust the NSF playback speed.
This doesn't effect the preview in FT but changes the exported NSF's speed. So playing in Nestopia (@ 60Hz) it sounds slow or fast, but when using FamiSlayer and a Ext Clock should sound the same as in FT!
Just have to work out the freq of the Ext BPM to set the engine speed.

Last edited by yogi (Jun 29, 2014 10:28 pm)

yogi
Offline
Jelly Stone park, MD USA

So to match an Ext Midi Clock:
Reset the "Engine Speed" in FT to:
(BPM x 24) / 60 = F in Hz  This will match the Ext Clock (@ 24 ppqn) and the NSF will sound the same as in FT. The Internal FT "Tempo" and "Speed" setting can also be used to fine tune the sync match smile
Yogi

m00dawg
Offline
Texas

Well that should make things reasonably easy! I need to wrap my head around some of this theory more, but that makes the solution potentially pretty straightforward.

Yogi, I'm not too familiar with the Pic family apart from with the MidiBox stuff (where many of the details are covered up) so I don't know how helpful I can be smile But if you do get that design off the ground, I'd love to do what I can to help test it!

For me Arduino was just an easy path to entry and I think augmenting ArduinoBoy to send some pulses out to some unused pins is probably within the realm of possibility as has already been discussed. So I may play around with that just to see where that goes while you're working on your PIC solution.

Do keep me posted though! At this point, I'm more after a solution that would work over one that is simply one I built. The net goal is being able to use the NES again as soon as I can.

yogi
Offline
Jelly Stone park, MD USA
m00dawg wrote:

Well that should make things reasonably easy! I need to wrap my head around some of this theory more, but that makes the solution potentially pretty straightforward.

Yogi, I'm not too familiar with the Pic family apart from with the MidiBox stuff (where many of the details are covered up) so I don't know how helpful I can be smile But if you do get that design off the ground, I'd love to do what I can to help test it!

For me Arduino was just an easy path to entry and I think augmenting ArduinoBoy to send some pulses out to some unused pins is probably within the realm of possibility as has already been discussed. So I may play around with that just to see where that goes while you're working on your PIC solution.

Do keep me posted though! At this point, I'm more after a solution that would work over one that is simply one I built. The net goal is being able to use the NES again as soon as I can.

You Betcha! ATM: HW built, only have small changes to make with the PIC and NES code. Want the keep the HW comp with the basic FamiSlayer package as well as allow advanced control for the SNROM ver .

Pad 1 controls unchanged.
Midi control on Pad 2 ATM:
Pulse Start on Midi Clock Ticks
Press or Release A on Midi RTM Start/Continue or Stop (Sync accepted by NES code only with A pressed)
Pulse Left for Frame Re-start on Midi CC#
Pulse Right for Frame FastFWD on Midi CC#

So it's moving along, will keep you posted
Yogi

m00dawg
Offline
Texas

Sounds awesome! I think you just alluded to it, but I'm guessing your solution may need the PowerPak modified mapper to work? I seem to recall reading where the PowerPak's current mappers do not support FamiSlayer out of the box? No big deal for me, but was curious.

yogi
Offline
Jelly Stone park, MD USA

Hummm. not sure, I don't have a PowerPak, just flash carts. But FamiSlayer should work (?)  PowerPak can run a NROM or a SNROM .NES? These are like the most common mapper.
For FamiSlayer and my mod file, there isn't any HW mods or such. The Sync converter just plugs in a controller port and it's just "pressing buttons"; it's all a software thang' on the NES.
Hope there isn't an issue with PowerPaks, can't imagine what the issue would be ?!?!
yogi

m00dawg
Offline
Texas

Maybe it was pulsar? I dunno some NES program I ran into had trouble due to using an odd mapper. That said, your version of VegaPlay (http://forums.nesdev.com/viewtopic.php?f=6&t=11322) /does/ indeed work with PowerPak. I used your example .NES and I noticed some songs would cause the NES to freeze. I'm guessing it's because the NSF didn't actually have song data there or something?

I don't have a 6502/NES toolchain setup yet so that's next on my list, at which point I can do additional tests. But apart from the freezing issue, yeah it worked like a champ! I'm guessing any sync additions you plan on adding should work fine too, but of course if you add them, let me know and I can easily test them on my PowerPak.