Quietly, and without much fanfare, nerds.de released an updated version of LoopBe30, a virtual MIDI patchcable driver, which now supports 64-bit operating systems, such as Vista 64 and XP 64.
Users of 64-bit operating systems have been getting the middle finger from many audio companies (such as these guys, although recently they have taken a slightly softer approach). It is/was really short-sighted, because 64-bit operating systems are, in general, higher performance and can address more RAM, which are both monumentally important to audio production. It doesn't matter that audio width greater than 32-bits provides little more (no perceptible) clarity than 32-bit. That is not the issue. If the OS has less overhead and greater bandwidth, more registers, and more RAM, the entire system will be faster, releasing resource pressure for the audio application, leading to overall higher performance. These guys understood and were the first to fully embrace 64-bit computing. Good for them.
Whoa, I went on a rant there. Sorry. The point of this post is to introduce you to the first (that I know of) 64-bit version of a virtual midi patchcable. What the heck does that do? It allows you to pipe midi-enabled software and hardware through multiple chains of midi within your computer. A good example is to pipe your sequencer's output through the mighty, mighty Midi-Ox, which will send the signal out your interface's midi-out to your hardware device.
Now 64-bitters can join the party! It's a niche market, for sure, but it's important when you rely on it!
It's worth noting that developing a 64-bit driver is not trivial because Microsoft requires that all 64-bit drivers be signed, which takes time and money, working with MS's quality labs, to make sure it won't crash the operating system and follows "best practices" set up by MS (a good thing). Thankfully, nerds.de took the time to do it.
I'll give a review of LoopBe30 in a later post. This is just to announce it's release! The big question for me? Will it work with the old school 32-bit Midi-Ox (another powerful program that refuses to make the jump to 64-bit at this point).
By default, ostensibly for security purposes, Microsoft makes it very difficult to modify folder permissions on C:\Windows\Tasks -- the "Scheduled Tasks" folder. You'll notice there is no security or sharing tab in the properties of this folder. The only way to modify it is to use CACLS.EXE, XCACLS.EXE, or XCACLS.VBS, or a similar program which manipulates the NTFS permission flags directly. This is not really the ideal way to do it. It's much easier to use Explorer's view, so you can be sure of the permissions you are assigning, without messing up other permissions.
I found a fairly reasonable work-around for this problem. It's a multi-step process, but it is worth the trouble. Although command line operations with CACLS is still required, you can use the Explorer interface to assign the new permissions before applying them to the Tasks folder.
Be VERY cautious when following these steps, or you may inadvertently open up serious security holes -- there IS a reason Microsoft locks this folder down tightly.
1. Open a command prompt.
XCOPY C:\WINDOWS\TASKS c:\TASKPERM /s /e /k /o
This will copy the tasks folder, in its entirety, including permissions and attributes. This essentially gives you a "mirrored" version of the scheduled tasks at C:\TASKPERM. It is probably not necessary to copy the tasks within the "Tasks" folder (the /S flag does this), but I like to be complete. :-)
3. Go to Windows Explorer and modify the ACL of C:\TASKPERM to suit your needs. Remember that if the user/group you are assigning permissions to should not be able to modify ALL tasks, it is important to set the "Apply To" attribute to "This folder only."
4. Back at the command prompt, type
CACLS C:\TASKPERM /S
Select the SDDL string (the stuff between the quotes) into the clipboard. Since the command prompt does not support line-wrapping text copy, you may have to post a larger string into notepad, and then trim out the stuff on either side of the quotes. You only want the bare SDDL string in the clipboard.
CACLS C:\WINDOWS\TASKS /S:
part with the SDDL string you put into the clipboard in step 4 -- do not include quotes.
7. Delete the C:\TASKPERM folder.
Not too bad, right? If you screw up your C:\WINDOWS\TASKS folder, the default ACL for Windows Server 2003 is D:P(A;OICIIO;FA;;;CO)(A;;0x1200ab;;;BO)(A;;0x1200ab;;;SO)(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)