I experience a very weird problem with Alphatrack.

A fellow studio bought one and I went there to install it. Installation went fine(I have installed over 7 AT's) and Cubase was able to see it properly.

The system runs Windows XP32 with Cubase 5.1.1 and the latest Alpha Track driver.

The problem is whenever the PC is restarted, Alphatrack refuses to send any midi messages  but can receive. For example, when I open Cubase, Alphatrack is found as a controller, with Alphatrack labeled in Midi IN and Midi Out and seems to receive midi data as when I rewind, forward the transport it shows the data on the LCD screen.

However it does not send any midi when I press its buttons or move the fader.

The only way to make it work is to unplug it from the USB port and plug it back again. Then it works until the next reboot.
AT is plugged straight on a USB port and there is no USB hub present.

I also tried the MIDIOX utility and indeed there is no midi sent from AT until I disconnect it from the usb port and put it on again. That means it is not a problem with Cubase either.

The motherboard is an ASUS P5Q and the CPU is a Quadcore Intel.

All other usb devices work perfect.

Is it possible that AT is defective?

I am writing this because I am totally frustrated by this issue.

I have bought two Alphatracks and I use them in my studio. I love the way they work.

However one of the main reasons I got Alphatrack in the first place was that it is portable and I would be able to use it anywhere...



When you use Alphatrack in a place where there is no proper grounding, it simply does not work.
I just mention the symptoms briefly as they have been mentioned here a hundred times: The display starts flickering, the fader does not move smoothly and it is jerky, playback in your DAW stutters because of false midi data sent from AT, the three knobs are useless as well.

I feel like I have been betrayed as a customer. IF this device was known to work only with grounded systems then there should be a BIG sticker on the box saying something like"WARNING: To use this device your Computer should be GROUNDED PROPERLY".

There is no way to guess if there is proper grounding everywhere you go.

My Alphatracks have been rendered useless countless times when I am out of my studio and I am fed up on it.

So, please, if there is a way to STOP this on DESKTOP systems (not laptop when you would advise to unplug the power which is unacceptable solution anyway) let us know. Give us some steps.
This problem is spread around the internet and still one year after I bought the device I have got no satisfactory workaround for that.

Please help your users.

Take care,



Not a solution when you are working with a desktop PC...

And I would NEVER do my mixing (which takes always more than 3 hours) on a laptop running with battery.

So we are at the beginning again...

Well, I went again to this fellow studio I had suggested Alphatrack to.

(By the way I guess they could easily have killed me because I suggested them this product and now they got two of them and none of them is working properly).

Well, the result is it MUST be a grounding issue. Why I say that?

Well, I noticed that while I was having my feet (yes my feet!) on the chair there was no problem. When I rest my one foot on the ground still no problem

Once I stepped to the ground with both feet and touched the encoder or the fared bang!
The weird shuttling took place all over again.

So yes, it is a ground issue.


I still insist this is something that is unacceptable and a SOLUTION/WORKAROUND has to be given. I don't know if you noticed but youtube is full of videos from users who have this problem with Alphatrack. I know that a system should be grounded but:

1)This shoudn't affect the workability of a device and
2) If it is actually affecting it, then this is very serious and there should be a big sticker in the box like "Warning-This device works only with properly grounded systems" or something like that.

I don't intend to be to critical. But I believe users should be informed correctly before they buy. As I said above, I don't have this problem personally because my laptop and my desktop PC's are properly grounded. But I hate the fact that I went to a studio and I still work with the mouse even though I have two Alphatracks lying around...

Honestly, I don't think this can be fixed as I believe it is a hardware flaw. The designers of the device should have taken into account this possibility and make the device immune to such problems.

However I would really be very happy to be proven wrong and see this fixed in a way.



I had this problem yesterday during a long session with Cubase 5. After a certain period of time even the slightest touch of the fader made the Aphatrack screen go to Shuttling mode and Cubase's cursor jumped to random positions!

Maybe has something to do with the latest plugin in general? Maybe AT gets bogged down with a lot of midi data coming in and out? I find this problem a bit related to my long waited to be solved problem here:

http://frontierdesign.com/forums/topic/ … 07-plugin/

For me, reopening the Cubase 5 project solved the problem. But when working for a long time it reappears. But right now I find AT unreliable to work in projects in front of customers.

Hope both issues get fixed as soon as possible. I have mentioned it before, I own three Alpha Tracks on three two completely different studios. Up to now I have been having numerous problems.

I believe the concept is great, I love the unit but it has affected my midi recording stability and the software problems let it down in my opinion.

Also, I think that the grounding issue is something to be more than considered. I don't know if it is fixable in a software/firmware level but it is unacceptable to exist. I took Alphatrack two days ago to a fellow studio for the owner to try it out and it was completely unusable due to grounding the grounding problem. Luckily I don't have this problem myself but I feel sympathy for the guys that do.

And from another scope, Frontier Design probably lose some customers on this. So maybe try to find a fix for this as well?(Sorry for hijacking the thread).


Central Scrutinizer wrote:

Where are you seeing the "Shuttle" indication? How is the behavior (playback) changing when this occurs? Is this similar to using the shuttle mode from AlphaTrack's tough strip (Shift+tap touch strip to enable/disable)?

Can both of you verify a few things for us?

1. Laptops or Desktop machines? And are they properly grounded if desktop.

2. If you hold your finder on the fader or encoder does the display show correct information, or something else?

3. If you run the self calibration (Shift+Stop+F4) does it improve?

I'm not sure where you are located but are you experiencing static electricity issues like we do up here in New England, or when the Santa Anna's are blowing on the west coast?

We'll try to repro this here.


1.Laptop and Desktop machines. Properly grounded.
2. Correct information
3.No, it doesn't help

I have managed to reproduce this problem and I think I have found out what it causes it.

If you touch the fader with the nail or with a finger with hardened fingertips, or on the base of the fader, then Alphatrack does not detect a valid fader movement and moves itself back to its original position(to see this behavior more easily move the fader with a piece of cloth to be very obvious). If this happens anytime (I admit it does not happen to me often but I am able to reproduce it) Alpha Track sometimes sends a shuttle message to Cubase and it skips playback or goes backwards. This is kind of a weird behavior and should definitely not be happening.

Same thing here.

I am able to reproduce it on three different Alphatrack units on three completely different systems.

Central Scrutinizer wrote:

Hi Domenico,

I understand your frustration, and you shouldn't have to disconnect the AlphaTrack to work. I have not heard of other reports of this, or seen other treads on it so I have to work from what you tell me and try my best to reproduce it. I just haven't been able to yet.

A few important questions that I am not sure about yet are:

If you change modes on the AlphaTrack so that the Bar:Beat display is not showing, do you still see this symptom?

If you go back to an earlier AlphaTrack Cubase Plug-in does the problem go away?

When you mention that you have disabled the AlphaTrack as an Input, how did you do that? Disabling the "All Inputs" box on the MIDI Port settings only removes AlphaTrack from the default "All Inputs" setting. It is still possible to select it a specific MIDI device as an input to any MIDI track.  This is why I mentioned that caution.

You're item #2 is interesting new information. Is there anything different about when it does happen and when it doesn't? Same project or different?
Also, I know I mentioned this before, but be sure all timestamping is turned off. That adds a huge midi load that will build the farther into a sequence you go.

One more question, are you chasing any other external timecode?



I have been very busy on some projects right now, but unfortunately I am not recording midi at the time so I cannot test thoroughly.

However let me answer to some of your questions as they may help:

The stuttering happens in random time. They happen on completely different projects. Even on very heavy ones or very very light with just a midi track and Halion One loaded.

When I say I disabled Alphatrack as an Input I mean that I went to the Midi Port Setup in Cubase and unchecked Alpha Track from the "All Inputs" section and from "Visible". That way, Alphatrack is neither visible in All Inputs neither can be selected.
Do you have any other way in mind that I could try? I believe I am secure this way but if there is something else I could try please let me know.

As far as timestamp is concerned, I have Windows Midi Timestamp deactivated(AT uses Windows Midi ports), however, I cannot deactivate Direct Music Timestamp as this results in late recording of midi notes.

I am not chasing any external timecode. The only midi devices on my system are :

Multiface II Midi IN/OUT
Motif ES8 connected via Midi to my Multiface
BCF2000(which I haven't used for some months now. Certainly not after I got Alphatrack :) )

Central Scrutinizer wrote:

Well, the amount of MIDI data it takes to drive the Bar:Beat readout should definitely not be enough to bog your system down. It is really only a small bit. But you can test that by selecting any mode other than PAN so that the info is not displayed to see if it has any effect. Cubase will only show that outgoing data if AT is displaying the location.

Also, if you revert back to an older Plug-In,  does this symptom disappear?

This sounds like a MIDI track or VSTi has maybe got the AlphaTrack selected as one of its MIDI ports accidentally.

You could also start with an empty project and see what happens when you add tracks to it.


What I describe is of course tested over and over again. What I mean is:

I have tested this with completely new empty projects with a very light VSTi loaded. It does not happen right away nor is it possible for a midi track to have Alpha Track assigned as a midi input since:

1. It does not exist in the midi inputs. I have disabled it.
2. It does not happen immediately. I have to record midi for half an hour or so to happen and sometimes it doesn't even happen.
3. When I disconnect Alphatrack the problem disappears.
4. Other Alpha Track users from other forums have reported this problem.

I know it's a bit hard to solve but I bought Alpha Track to use it (and have recommended it to a lot of colleagues and students) and I don't think that unplugging it from my PC is a solution.

Any ideas?

Central Scrutinizer wrote:

When you say "recording midi", do you mean when recording automation from AlphaTrack, or do you mean notes from your MIDI keyboard, etc?

Cubase would have always shown controller MIDI traffic to/from the AlphaTrack regardless of what plug-in version. The traffic that you see when doing these tests is normal and definitely shouldn't be enough to cause problems.

If you have MIDI echo turned on for your keyboard or other midi devices then you may have a MIDI loop when recording which would cause huge amounts of unwanted traffic and potentially bog your computer down. Particularly if timestamping is also enabled.


I mean recording notes from my midi keyboard.

I know that I was always shown of the midi traffic this is totally normal. The thing that wasn't happening before was that the midi output was like when you are touching the fader when recording midi data! I mean when someone was recording midi or audio or anything there was no additional midi output activity from Cubase to Alphatrack! The only time when there was midi output activity from Cubase to Alphatrack was when you pressed a button on Cubase in order to show that action to Alphatrack as well. But after the latest plugins there is CONSTANT output activity from Cubase to Alphatrack when recording or playback and that's what I suspect is causing the computer to bog down. Too much amount of midi information? I think this is where the problem lies.

Central Scrutinizer wrote:

I have been doing some tests with Cubase 4 and an AT that maybe you can try too. Here are my observations.

With the "Don't You" demo project running and all automation turned off. (You can use one of your own projects)

1. If the AlphaTrack is in PAN mode so that the Bar:Beat info is displayed I see a normal outgoing MIDI pulse rate of about 2 or 3 per second. (Watching the Cubase transport bar midi output meter).

2. If I touch (but do not move) the fader, or any encoder, or change modes so that the Bar:Beat info is not displayed, the midi output stops completely.

3. If I have automation on the selected track and turn Read on, then that will add midi activity relative to how much automation there is.

Can you tell me what you see if you repeat this same test?



I think we are in the good track of tracing the problem here.

I did the tests you suggested and I got the same behavior that you describe.

The thing is that before the new plugins the midi output meter was not sending info when recording midi. Like when you touch the fader or when you touch a knob. That's why I suspect that this continuous transmit of midi data has something to do with the conflict.

Central Scrutinizer wrote:

Hi Domenico,

I am very curious about the MIDI Port assignments that you mention. You have tried the AlphaTrack's MIDI ports to be either 'Windows MIDI' , or 'Direct Music'.

On the "MIDI Port Setup' panel it should set it to Windows MIDI with Timestamping turned off, like your original settings. When you then check the AlphaTrack's own MIDI In/Out port assignments they should both be set to itself (AlphaTrack).

Also, check any MIDI tracks that you have in your project and make sure none of them accidentally have the AlphaTrack selected as an input or output port.


OK, these were my initial settings. I have checked again and again that the Alphatrack is not assigned as an input in any midi track and have excluded it from the "All Midi Inputs".

So Windows Midi Ports and Timestamp deactivated was the first setup and I still have problems.

Central Scrutinizer wrote:

Ah, ok. None of that was changed at all in the recent updates. Actually that Bar/Beat display is just reading data that Cubase is already generating. We aren't really asking it to do any extra work.

But if disconnecting the AT seems to cure your problem then it sounds like maybe there is some other setting that is causing excess MIDI load with the AlphaTrack in your case.

You might try resetting all MIDI drivers from the MIDI Port Setup. Also, if you have timestamping enabled at the bottom of that page it might bog things down. Timestamping adds a lot of MIDI overhead. Check that AlphaTrack In is NOT enabled as an "All Inputs" device too.

Let us know if any of this helps or not.


I am not quite sure, but I don't remember Alpha Track receiving so many Midi data before from Cubase.  The midi out light in Cubase used to send so many midi events only with my BCF2000 in the past.

Anyway, thank you for your suggestions.

Actually, before posting here I did some tests on my own and after no one of them succeeded only then I decided to post.

So here are the tests:

Before doing anything the configuration was as follows:

Multiface II ports : Direct Music IN/OUT

Alpha Track: Windows Midi

System Timestamp checked for Direct Music Only

I changed this configuration with this:

Multiface Midi: Direct Music

Alphatrack: Windows Midi

System Timestamp checked for Direct Music and Windows Midi


Multiface and Alphatrack on Windows Midi ports w/ Timestamp enabled.


Multiface: Direct Music (Emulated)

Alphatrack: Direct Music (Emulated)

Timestamp Checked.

Multiface: Direct Music Emulated

Alphatrack: Midi In: Direct Music Emulated 
                   Midi Out: Windows Midi

System Timestamp enabled to both Direct Music and Windows Midi.

I have tried many different combinations as you can see :)

Some of them worked for a while, then exhibited the same problem.

Do you have any combination in mind that is likely to work?

I have made sure that Alphatrack is NOT shown in the All Inputs. Especially when I found out that Alphatrack can transmit MIDI NOTES as well! (Was mistakenly as the default midi device for Chainer standalone host). In fact, even by touching the fader  I could play notes!

Please let me know if the info I provided you with above is of any help and if you have something to suggest. Also do not hesitate to ask me for more info if necessary.



Central Scrutinizer wrote:

Hello Domenico,

I'm not sure what you mean by the "Timecode" reference in the new AlphaTrack plug-in. We didn't add, or make any changes with regards to timecode display or synchronization.  The update should only affect how the Solo, Mute, Rec Arm function update for the AlphaTrack itself.

If you remove AT from your Device Setup does this symptom still occur? If so then it must be caused by something else.

Tell us about this timecode thing and we'll see if we can find any link to our plug-in work.



By timecode I mean the feature that was added in Alphatrack even before the latency fix problem, and I mean the Bars, Beats and Ticks that are now displayed on the Alphatrack LCD screen. They were not there before, so, when a Cubase project was playing, it was not transmitting midi data constantly to Alpha Track. Now it is sending messages all the time. And since that happened my problem also began.

Up to now, when I unplug Alpha Track from my system the problem does not occur.




I am using Cubase 4.5.2 with Alphatrack and an RME Multiface II interface.

I was really happy to see the new plugin released and the latency problems being corrected.

However, with the latest releases of the plugins 1.06 and 1.07 I found out that a big problem was introduced.

Now when I record midi in Cubase, randomly, Cubase stutters for 2-3 seconds(playing the same chunk of audio) and while this is happening the notes I record are recorded on the top of each other.

This was not happening when I was using the previous versions of the Alphatrack Cubase plugin(I mean the 1.05 and earlier) and I have not changed anything on my system at all.

The only thing I can suspect is the new timecode display that was introduced with the Alphatrack new plugin. As far as I can see now Cubase is constantly sending midi data to the Alphatrack in order to have the timecode synchronized and maybe this is causing the midi stuttering problems.

I have been painstakingly trying all the different midi ports in Cubase( Windows Midi, the defaults for Alphatrack, Direct Music, Direct Music Emulated) with no success whatsoever.

The problem keeps happening at random times (that's why it is very difficult to reproduce) and it was NOT happening with the plugins prior to the "Timecode"versions. It doesn't happen when I disconnect Alphatrack all together from my system as well.

This is really frustrating, I don't know if something messed up with the Cubase midi machine(or windows?) but right now I am in the middle of nowhere and I am not sure on what to do to cure the problem.

I searched Cubase forum and users who are experiencing the same problem are also having Alphatrack.

Can you give any help please? This is really serious.

Central Scrutinizer wrote:

Hello Domenico,

Ya, I think maybe you missed something. If you check the Cubase/Nuendo guide at http://frontierdesign.com/download/pdf/ … v1.0.4.pdf you will find that F1 and F2 are used to control Page/Prameter Up and Down in the various button modes. For example F1/F2 select bands in EQ mode, or sets of parameters in Plug-In mode.

Hope that helps.



Hmmm...not exactly. These buttons are not used at all in the mode that I use Alphatrack most of the time. Which is the Pan Mode. OK, I understand that the buttons function in the other modes but we could also have an option to use them in Pan mode.

Not something I can't live without, just a suggestion!

I have a question for a long time, as the way things are now seem rather illogical to me.

I am using Cubase4 with Alphatrack and I am always wondering why I cannot assign functions to the F1 and F2 keys. For example I would like to assign my Mixer window to the F1 key without having to press the SHIFT key as well.

Why isn't this possible in Cubase? Those buttons are rendered useless this way.

Or maybe I have missed something?


(5 replies, posted in AlphaTrack:User Forum)

frenzy wrote:

Hi everybody!

Just tested AT in Cubase 5 and it seems like the two [Change Track] button are dead. They work fine in Cubase 4 and Nuendo 4.

Has anybody else experienced the same bug in C5?

I'm very happy to discover that the Solo-lag-bug has been fixed. Now I don't have to map the Solo-function to F4 anymore.

Thanks for the update!


This is important. I am going to update to Cubase 5 soon so I hope everything is ok.

You could always ask at the Cubase forum as well. Right now I am still on V4.

Ok, I got what you were meaning.

Yes, they work OK when using the keystrokes that way.

So there is something wrong with the SHIFT key combination only.


Hello Jerry,

First of all thank you for the immediate reply. I am sure that all Alphatrack users will appreciate this as I do.

simplemind wrote:

Hi Domenico,

Could you do me a favor and go to the automation mode and try the Write/Read toggle there and see if that works the way you'd expect. I bet it does

Could you be more specific on this? I am not sure I get what you want me to do. Could you clarify exactly what you want me to do?

I would be happy to try the new plugin! Please feel free to send it to me if you wish so.

Thank you for supporting the right way a great device.



(4 replies, posted in AlphaTrack:User Forum)

Not all issues are fixed since the WRITE/READ Automation buttons suffered the same problem.

And this is one of the most important aspects of Alphatrack. To Write and read automation.

See here for more details:


Today I was really happy to see finally the post that informed us that the new plugin for the Alphatrack that solves the unacceptable latency problem with Alphatrack and Cubase was FINALLY released!

So the first thing I did was to test it.

Well, I am completely frustrated. No, the new plugin does not fix all the latency problems.

Let me be more specific so this may help solve this faster.

The SOLO button latency is fixed. Well done!

The Rec Arm button latency is also fixed.


The Write/Read automation buttons latency are NOT FIXED!
That means a user STILL cannot know for sure whether he is writing automation or not unless he has opened the automation lane track for EACH channel.

Let me be even more analytical.

To activate Write Automation in Cubase you press and hold SHIFT in the Alphatrack while SHIFT pressed you press the Rec button. To Read Automation you do the same thing but press PLAY button on Alphatrack.

While doing this the latency is STILL there. Which means if you press the two keys you HAVE to wait for 1-2 seconds before releasing SHIFT in order to activate either read or write automation. Unless you do that, you end up writing no automation or read automation, EVEN IF THE BUTTON IN CUBASE SEEMS PRESSED which makes it even more dangerous and misleading.

I don't know why this issues are not fixed yet, since me and other users have pointed out the problems in our previous posts.

I hope that this issue will be fixed soon so that we will not have to wait for a month or so again...

I own 3 units and I have been really patient up to now.

Please let us know if you acknowledge this issue and when it will be fixed.


Central Scrutinizer wrote:

Hello Dom,

This issue came about with version 4 of Cubase/Nuendo and is something we are aware of and are in the process of addressing. We hope to have something available very quickly. I can't give you an exact date yet but it is of priority.


Hi there,
Thank you for the reply,

I hope this is something to be fixed soon. It is discussed too much in the Cubase/Nuendo community. Sadly this problem makes Alphatrack unreliable to work with in those Sequencers. For me it is a pain to even write automation with Alphatrack, which is one of the main reasons I bought it for.

I am really looking forward to news from you. I hope I can see Alphatrack working as a charm and as it should in Cubase.

Thank you in advance,



I am the proud owner of two Alphatrack units.
I use them in Cubase 4.5.2. I have installed the latest Alphatrack drivers and the latest plugin for Cubase.

However I experience a severe problem in Cubase which renders my Alphatrack almost useless for any serious work.

The buttons Solo, Rec arm, Write & Read Automation present latency when pressed in the AT.

To be more specific:
When I press solo on Alphatrack, the action is immediately mirrored in Cubase but the track in fact is NOT soloed but gets soloed after 1.5-2 seconds!
Same happens with Rec arm and Automation buttons.
I was working on a project and I already lost many takes thinking that the rec arm button was activated when it wasn't!

Not to mention that I am really dubious each time I record automation if I am REALLY recording the automation. I have found myself many times going back to see that I have been painstakingly making fader rides without having recorded any automation at all!

This is really a huge problem and I have seen many other users suffering from it as well. I also have a BCF2000 controller and it works fine with all the functions I described above. So it must be something wrong with the Alphatrack plugin for Cubase.

In fact many users said that it has to do with some Flags in the configuration which we users are not able to modify, so this must be done by Frontier Design.

Please can you give some feedback on this? I wanted to buy two more units for my personal studio but now I am thinking of returning even the ones that I have bought.