Hello.
I am debating a point, and I'd like to throw it open to anyone who'd like to comment.
Obviously our job is to provide you with as much as we can for your money.
I don't think anyone wants to question the quality of the software, but what I want to discuss is other stuff we can do to make your world a bit better.
Personalised installers look like a good thing - zero hassle for you.
Perhaps also including an uninstaller, so you can easily and quickly install/uninstall bits?
People like to customize things - I've changed things so you can customize our UIs... but...
When I ran the very first TBK beta, I put the betatester's name across the knob. And people loved it!? Honestly, I don't know why. It WAS discrete, but it was still prominent. I can almost see the appeal... but I don't really get it. But----- if it makes people happy, I'll do it! :)
I've been thinking that maybe people would like to have their names on display on the UIs of plugins?
Basically, I'd like to do some things to reward paying customers for being lovely and supporting the cause.
People who support the cause without paying are ok, because they keep the name alive... but without the paying customers, I'd be working in a supermarket, and no-one would have any plugins!
Remember, I'm the last one in (most recent hire), so I'll be the first one out!
I'm well up for any kind of online communities you want, I'm happy to go and hassle people for whatever purposes you can devise.
Tell me what you want (besides more software... I'm on that!) and if people want it, it will happen :)
Please, talk to me!
Wednesday, August 30, 2006
Copy protection and demo periods.
Hey,
So, today, I fixed a bug in TBK. As I mentioned before elsewhere, if the demo runs out, it just stops passing audio. It doesn't tell you anywhere, unless you click on setup.
This is relevant, 'cause people forget to register their plugins (they just install em, and forget about the registration files), and then the demo period expires. I'm gonna do new installers that fix this, but right now, something needs to improve, so that's what i'm on.
When it's expired, the plug is basically useless until you register it. So.
Now, when it's expired, it comes up in setup mode automatically [and stops you switching out] - basically the plug ui becomes a big warning saying "it's over! register me!"
Potentially, we can also pop up a messagebox to warn you. Is that too annoying? Or is that really useful... Either there's no box, and you wonder why it's not passing audio [it mutes the channel], and have to open the ui to find out... or it tells you straight up, once per session...
Thoughts please people :)
So, today, I fixed a bug in TBK. As I mentioned before elsewhere, if the demo runs out, it just stops passing audio. It doesn't tell you anywhere, unless you click on setup.
This is relevant, 'cause people forget to register their plugins (they just install em, and forget about the registration files), and then the demo period expires. I'm gonna do new installers that fix this, but right now, something needs to improve, so that's what i'm on.
When it's expired, the plug is basically useless until you register it. So.
Now, when it's expired, it comes up in setup mode automatically [and stops you switching out] - basically the plug ui becomes a big warning saying "it's over! register me!"
Potentially, we can also pop up a messagebox to warn you. Is that too annoying? Or is that really useful... Either there's no box, and you wonder why it's not passing audio [it mutes the channel], and have to open the ui to find out... or it tells you straight up, once per session...
Thoughts please people :)
Why I am a GEEK, part 1.
Version numbers are a serious pain in the ass.
Today, I have edited millions of files, and thrown around loads of code, so that I have one file with all our version numbers in, so I can update them when needs be.
It was painful, but it worked; mostly because apple allow you to run your Info.plist file through the C preprocessor. I love apple.
Today, I have edited millions of files, and thrown around loads of code, so that I have one file with all our version numbers in, so I can update them when needs be.
It was painful, but it worked; mostly because apple allow you to run your Info.plist file through the C preprocessor. I love apple.
Thursday, August 24, 2006
AU and MIDI [mac specific]
Uuuuuugh
So.
We wanted MIDI input for the TBK AU.
Now, if you want midi input, you need to be a MusicEffect (or a synth, which we aint).
So, I hacked and hacked, and now we're a musiceffect.
I've been playing midi to TBK in Logic and it loves it. Filth.
Now, the catches:
1) To play midi to a plugin in logic, you have to instantiate the TBK on an instrument channel, and select a "sidechain input" as the audio input. Then it all just works.
2) I can register as either an Effect, a MusicEffect (with midi in) or BOTH.
If I register as Effect, you don't get midi.
If I register as MusicEffect, you get midi, but your old sessions stop working, 'cause it can't find TBK any more
If I register as both, everything keeps working, you get midi... but TBK shows up twice in your plugin menus. Definitely the least evil option. I'm going with this.
If anyone has a fix, or a better idea- or some magical hackery - please please please let me know!
Dave.
So.
We wanted MIDI input for the TBK AU.
Now, if you want midi input, you need to be a MusicEffect (or a synth, which we aint).
So, I hacked and hacked, and now we're a musiceffect.
I've been playing midi to TBK in Logic and it loves it. Filth.
Now, the catches:
1) To play midi to a plugin in logic, you have to instantiate the TBK on an instrument channel, and select a "sidechain input" as the audio input. Then it all just works.
2) I can register as either an Effect, a MusicEffect (with midi in) or BOTH.
If I register as Effect, you don't get midi.
If I register as MusicEffect, you get midi, but your old sessions stop working, 'cause it can't find TBK any more
If I register as both, everything keeps working, you get midi... but TBK shows up twice in your plugin menus. Definitely the least evil option. I'm going with this.
If anyone has a fix, or a better idea- or some magical hackery - please please please let me know!
Dave.
TBK MIDI Control Mode - take 2! the KEYS!
Hey people.
Part 1 of today's antics.
I've added in a feature to TBK whereby you can play keys, and it'll set the cutoff to that frequency. It's a preference, so it won't mess up your existing stuff...
Releasing sooooooonnnnnn
Dave.
Part 1 of today's antics.
I've added in a feature to TBK whereby you can play keys, and it'll set the cutoff to that frequency. It's a preference, so it won't mess up your existing stuff...
Releasing sooooooonnnnnn
Dave.
Tuesday, August 22, 2006
VST2.4... the saga continues
Hey,
Well it's all good news over here now... but there was a scary moment earlier...!
Like probably everyone out there, our plugins are VST, with interfaces to convert to AU, DX and RTAS.
When I did the port, I had to fix loads of stuff in the interface code... everything went fine... except... RTAS... Digi (who rock) provide sample code for how to write a VST->RTAS interface layer, and it passes through "Draw" and "Mouse" messages to the VST. However, the interfaces it was calling no longer exist in 2.4, so I figured it would sort itself out, and just took out that code.
It did not sort itself out.
So, I had to paste in the old handling code to the top-level of the GUI implementation (which the RTAS interface has a handle to), and put the old code back in. It's not evil, because I'm adding the old code back in _in my code_, rather than in the VST libraries, and because it's still absent in lower layers, noone gets hurt! :)
Little bit sticky... but essentially 10lines of code pasted into a headerfile, and the world was well again...
Phew. Well. I've finished the 2.4 upgrade... what shall I tamper with now... hmmmm...
Well it's all good news over here now... but there was a scary moment earlier...!
Like probably everyone out there, our plugins are VST, with interfaces to convert to AU, DX and RTAS.
When I did the port, I had to fix loads of stuff in the interface code... everything went fine... except... RTAS... Digi (who rock) provide sample code for how to write a VST->RTAS interface layer, and it passes through "Draw" and "Mouse" messages to the VST. However, the interfaces it was calling no longer exist in 2.4, so I figured it would sort itself out, and just took out that code.
It did not sort itself out.
So, I had to paste in the old handling code to the top-level of the GUI implementation (which the RTAS interface has a handle to), and put the old code back in. It's not evil, because I'm adding the old code back in _in my code_, rather than in the VST libraries, and because it's still absent in lower layers, noone gets hurt! :)
Little bit sticky... but essentially 10lines of code pasted into a headerfile, and the world was well again...
Phew. Well. I've finished the 2.4 upgrade... what shall I tamper with now... hmmmm...
VST Users! Love me! :)
Hey,
I just added double-precision (64bit float) to the entire range of sonalksis plugins.
They've always been double-precision internally, and now you can run double-precision between things.
It took about 5 minutes, after getting the VST2.4 port completed successfully ;)
I just added double-precision (64bit float) to the entire range of sonalksis plugins.
They've always been double-precision internally, and now you can run double-precision between things.
It took about 5 minutes, after getting the VST2.4 port completed successfully ;)
I am such a pedant.
So
I decided to rid my world of warnings.
Never more will a NULL and a 0 be used incorrectly!
Actually, I did this ages ago for the VSTs and AUs. Leave warnings ALL on, tidy the thing up.
That's another reason to like VST... there's nothing implicitly wrong with the code; it doesn't throw up many errors... and, yes, I did fix the handful that it did.
AU- same deal; nice clean code.
AUs and VSTs have been building clean for ever.
RTAS is a different story. RTAS was throwing up ~1200 warnings. Mostly (almost all) warnings of nonvirtual destructors in classes with virtual functions. This is a violation of the "effective C++" rules. However, it's meant to be that way. It's correct, for a variety of reasons, for the digi classes to have nonvirtual destructors alongside virtual functions. So.. just disable the warning for that file, right? GCC doesn't do that yet. Ugh.
Disable the destructor warning? You know the code is otherwise clean... No. -Wmost switches it back on somehow. I've never really understood XCode's build system. Well; I think I do, it's an inherited overridable system, and as such it's pretty straightforward. But, it IS magic when things start to interact within the compiler. Or just plain lie to you.
Anyway. I switched off -Wmost, and was suddenly left with a sensible set of warnings!
Entire build is now warning free.
I'm a pedant, but I do rock ;)
I decided to rid my world of warnings.
Never more will a NULL and a 0 be used incorrectly!
Actually, I did this ages ago for the VSTs and AUs. Leave warnings ALL on, tidy the thing up.
That's another reason to like VST... there's nothing implicitly wrong with the code; it doesn't throw up many errors... and, yes, I did fix the handful that it did.
AU- same deal; nice clean code.
AUs and VSTs have been building clean for ever.
RTAS is a different story. RTAS was throwing up ~1200 warnings. Mostly (almost all) warnings of nonvirtual destructors in classes with virtual functions. This is a violation of the "effective C++" rules. However, it's meant to be that way. It's correct, for a variety of reasons, for the digi classes to have nonvirtual destructors alongside virtual functions. So.. just disable the warning for that file, right? GCC doesn't do that yet. Ugh.
Disable the destructor warning? You know the code is otherwise clean... No. -Wmost switches it back on somehow. I've never really understood XCode's build system. Well; I think I do, it's an inherited overridable system, and as such it's pretty straightforward. But, it IS magic when things start to interact within the compiler. Or just plain lie to you.
Anyway. I switched off -Wmost, and was suddenly left with a sensible set of warnings!
Entire build is now warning free.
I'm a pedant, but I do rock ;)
Monday, August 21, 2006
Updating to VST 2.4
So, updating to VST2.4 is on my list of things to do.
We've got full double-precision processing internally (and have had from day one, because we rock), so it's just adding a double-precision input and output connection to the host. No big deal. Real easy.
Guess what! WRONG!
If you've ever written a VST plugin, you'll know that the SDK is a bit messy... there are a few things that you sort of have to assume, or figure out for yourself... but it's not BAD. It's not TERRIBLE. The sheer number of VST plugins is evidence to that. It's not messy, it's a bit scruffy. Rudeboy like even.
It's hard not to like VST. It has an elegance and minimalism to it. An ill type flow that makes it all groovy.
Steinberg are smartening up. Oh lord no.
So. You need to work on Win64... this means that some things need to change.
No, part of the scruffiness of VST was that everything was just assumed to be 32bit. And, because it was, everything worked, and there was no problem at all.
So, let's have thousands of lines of code, expecting the C type "long". Now, let's change all the functions to use "VstInt32" instead of "long" (to be explicit and mark out what will change between 32bit and 64bit versions).
Because of something that you don't care about, but which is a very very good thing, called "polymorphism" in C++, if you don't remember to change EVERY appropriate instance of "long" to "VstInt32" in the definitions of ALL your functions, then random bits of your plugin will fall off. Literally. Bits you were relying on... like... the UI... will just stop working.
**** WHEN YOU UPGRADE TO VST2.4, GO THROUGH ALL YOUR CLASS DECLARATIONS LINE BY LINE, AND VERIFY THAT THE TYPES ARE CORRECT. USE STEINBERG'S ONES. DO NOT RELY ON THE TYPEDEFS RESOLVING THEMSELVES, BECAUSE THEY WON'T ****
And then, when your code actually compiles again, adding double-precision processing support is a synch! :)
But... factor in a few hours of very careful code review.
We chose to stick with the old VSTGUI, rather than moving up to 3, because our current VSTGUI is heavily tested, and works. Merging the old VSTGUI with the new VST SDK was easy enough... although a bit dodgy in places. You MUST be using QUARTZ if you want to keep the old VSTGUI on mac. This is because the VSTGUI QUARTZ implementation registers a carbon eventhandler, and makes all the mouse and key stuff work by magic. VST has now stopped passing mouse + draw stuff up to the gui, so you wanna be on quartz, or you will probably lose your UI!
But anyways... I'm most of the way through with catching bugs... and I've just got to make everything compile smooth ;)
Hope this helps VST2.4 peeps :)
We've got full double-precision processing internally (and have had from day one, because we rock), so it's just adding a double-precision input and output connection to the host. No big deal. Real easy.
Guess what! WRONG!
If you've ever written a VST plugin, you'll know that the SDK is a bit messy... there are a few things that you sort of have to assume, or figure out for yourself... but it's not BAD. It's not TERRIBLE. The sheer number of VST plugins is evidence to that. It's not messy, it's a bit scruffy. Rudeboy like even.
It's hard not to like VST. It has an elegance and minimalism to it. An ill type flow that makes it all groovy.
Steinberg are smartening up. Oh lord no.
So. You need to work on Win64... this means that some things need to change.
No, part of the scruffiness of VST was that everything was just assumed to be 32bit. And, because it was, everything worked, and there was no problem at all.
So, let's have thousands of lines of code, expecting the C type "long". Now, let's change all the functions to use "VstInt32" instead of "long" (to be explicit and mark out what will change between 32bit and 64bit versions).
Because of something that you don't care about, but which is a very very good thing, called "polymorphism" in C++, if you don't remember to change EVERY appropriate instance of "long" to "VstInt32" in the definitions of ALL your functions, then random bits of your plugin will fall off. Literally. Bits you were relying on... like... the UI... will just stop working.
**** WHEN YOU UPGRADE TO VST2.4, GO THROUGH ALL YOUR CLASS DECLARATIONS LINE BY LINE, AND VERIFY THAT THE TYPES ARE CORRECT. USE STEINBERG'S ONES. DO NOT RELY ON THE TYPEDEFS RESOLVING THEMSELVES, BECAUSE THEY WON'T ****
And then, when your code actually compiles again, adding double-precision processing support is a synch! :)
But... factor in a few hours of very careful code review.
We chose to stick with the old VSTGUI, rather than moving up to 3, because our current VSTGUI is heavily tested, and works. Merging the old VSTGUI with the new VST SDK was easy enough... although a bit dodgy in places. You MUST be using QUARTZ if you want to keep the old VSTGUI on mac. This is because the VSTGUI QUARTZ implementation registers a carbon eventhandler, and makes all the mouse and key stuff work by magic. VST has now stopped passing mouse + draw stuff up to the gui, so you wanna be on quartz, or you will probably lose your UI!
But anyways... I'm most of the way through with catching bugs... and I've just got to make everything compile smooth ;)
Hope this helps VST2.4 peeps :)
Friday, August 18, 2006
Free-G!
Hey Peeps!
So, it's official now, we're releasing a free plugin! :D
[This started elsewhere on the blog!]
What you get:
- Really nice metering [pre / post fader], [peak, hold and rms]
- A really tall fader
- Ability to use it as a +/-24dB trim, or a channel fader
- Phase invert
- Mute
So... do you want a Bypass button on the UI?
Here's how the thing works, btw... There's a button on the bottom, marked "Trim".
When you boot the plugin, you get a channel-type fader, from +18 to -96.
Hit Trim, and the fader labelling changes, to +/-24 db of where the fader is set, so that you can
do extra accurate fader positioning.... or, just boot it up and hit trim to pad or gain a few db.
How does that sound?
So, it's official now, we're releasing a free plugin! :D
[This started elsewhere on the blog!]
What you get:
- Really nice metering [pre / post fader], [peak, hold and rms]
- A really tall fader
- Ability to use it as a +/-24dB trim, or a channel fader
- Phase invert
- Mute
So... do you want a Bypass button on the UI?
Here's how the thing works, btw... There's a button on the bottom, marked "Trim".
When you boot the plugin, you get a channel-type fader, from +18 to -96.
Hit Trim, and the fader labelling changes, to +/-24 db of where the fader is set, so that you can
do extra accurate fader positioning.... or, just boot it up and hit trim to pad or gain a few db.
How does that sound?
Thursday, August 17, 2006
You like customising your UIs [mac specific] ?
Well, you'll be pleased to know that I've just restructured things so that we now have .bmp files inside the plugin bundles! :)
Those .rsrc files are GONE!
This means, you can open up the plugin, and reskin your graphics.
This bring the wonderful result that I won't need to support the process by generating files for people ;) you can just send around the bmps.
Of course, if we update the UIs... [ ;-) ] you'd have to start again (because things would probably move around!)
PCwise... ugh. resource files. it's NEVER easy to reskin things on PC unless you're happy using resource editing tools. What +DO+ people use to skin plugs on pc?!? If you can find something that works for people, I can bring it through... but I don't REALLY want to spend a week adding an interactive skinnability mechanism to the plugs [read: that'd be REALLY boring]
Ezzzzzz
Those .rsrc files are GONE!
This means, you can open up the plugin, and reskin your graphics.
This bring the wonderful result that I won't need to support the process by generating files for people ;) you can just send around the bmps.
Of course, if we update the UIs... [ ;-) ] you'd have to start again (because things would probably move around!)
PCwise... ugh. resource files. it's NEVER easy to reskin things on PC unless you're happy using resource editing tools. What +DO+ people use to skin plugs on pc?!? If you can find something that works for people, I can bring it through... but I don't REALLY want to spend a week adding an interactive skinnability mechanism to the plugs [read: that'd be REALLY boring]
Ezzzzzz
Wednesday, August 16, 2006
Going quiet for a bit...
Ezzzz
If I don't reply to postings until... say... friday-ish, it's because:
1) I have to write some code...! I need to actually make some things for you all :)
2) I'm going out for drinks tonight and it's going to be messy :-D
3) You should all come to Swerve at The End tonight!
So, I'm going to focus on beer, and then working, in that chronological order... but with equal priority. I've been working verrry late recently, and I need to go relax for a bit ;)
Back in a bit people :)
Dave.
If I don't reply to postings until... say... friday-ish, it's because:
1) I have to write some code...! I need to actually make some things for you all :)
2) I'm going out for drinks tonight and it's going to be messy :-D
3) You should all come to Swerve at The End tonight!
So, I'm going to focus on beer, and then working, in that chronological order... but with equal priority. I've been working verrry late recently, and I need to go relax for a bit ;)
Back in a bit people :)
Dave.
Tuesday, August 15, 2006
Input Trims/Gains on plugins
Heya
Is it just me that regularly chucks audio at +12dBFS into plugins?
I kinda rely on having +/-24dB of gain on things. On input AND output!
I want to add input trims to things. Particularly 315 and 719.
Please post "me too" to second the idea!
Cheers,
Dave.
Is it just me that regularly chucks audio at +12dBFS into plugins?
I kinda rely on having +/-24dB of gain on things. On input AND output!
I want to add input trims to things. Particularly 315 and 719.
Please post "me too" to second the idea!
Cheers,
Dave.
Copy Protection
We're redoing the installers, as you probably know, so we're looking at ways to fix up our copy protection so that it's easier for people to handle. I'll explain a bit about it, but first, I need to make the following point:
PROGRAMMERS HATE COPY PROTECTION
PROGRAMMERS HATE COPY PROTECTION
PROGRAMMERS HATE COPY PROTECTION
It's basically the worst thing in the world for a programmer to have to deal with, because it just gets in the way of trying to work. If it annoys YOU as a customer, using it, say, once... consider how much it annoys ME using it several thousand times.
Reasons to not have copy protection:
1) I hate it.
2) Our software gets cracked the day it comes out, and people are using cracked copies on the day of release ANYWAY.
3) It annoys the HELL out of users.
Reasons TO have copy protection:
1) It protects the investment of customers.
Unfortunately, as utterly bizarre as it sounds, that's a really strong reason.
If you're a customer, we have to put something in place which makes our software not free, because otherwise we're being disrespectful to you by asking you to pay for something which there are no restrictions to using free of charge.
Personally, I'd like to give stuff away free to everyone, but alas, I'm not naive enough to believe that I'd be able to go on doing that for very long before someone asked me for some rent, and I realised I was skint... the more money we make, the more plugins you get. [Or, in the case of recent history, the more mindblowingly groundbreaking a product you get...]
So in our case, you who pay for software invest in the future of that software... and for R&D that will give you more of that quality software that you love
So... our copy protection has a bit of an issue. In its eagerness to NOT annoy the user with windows telling you things like "err, hang on, you need to actually register this", after it has expired, it just locks itself into bypass [or won't pass audio]. So, when your 30days demo has expired, it doesn't tell you... it just stops working. To a legitimate user who didn't realise that they had to register it, after 30 days, our software appears to break!!! You open up your session and it just sounds different... and you wonder why!
We're thinking about how we can improve things. This issue of dilligence to protect investment means that we MUST do SOMETHING.
Currently, you go to the registration site, enter your details, and it sends you a license file
which will register your plugins and make them work forever. (though it has to be done manually)
We need to wire SOMETHING into the installer to sort this. But what if your studio computer ain't on the 'net?
Things we've been considering:
1) I got some speak'n'spell samples. I'm going to splice them up, a-la Cassetteboy, to say "Your Sonalksis plugin has expired. Please register them... etc" when you instantiate an expired plugin or open a session.
2) A BIG MESSAGE BOX TO TELL YOU THAT THEY HAVE EXPIRED AND WHAT YOU NEED TO DO TO REGISTER THEM.
3) A page in the installer that tells you ALL about registration (because you really care), or perhaps something that takes your details, and tries to connect to the 'net (or generates a link file if it can't?) and downloads+installs your license file.
4) A license manager application which is your friend.
Basically though, you know way more about this than we do, so we want you to know that we're taking it seriously, but really we want to know what you think.
Please tell us! I hate copy protection.
Dave.
PROGRAMMERS HATE COPY PROTECTION
PROGRAMMERS HATE COPY PROTECTION
PROGRAMMERS HATE COPY PROTECTION
It's basically the worst thing in the world for a programmer to have to deal with, because it just gets in the way of trying to work. If it annoys YOU as a customer, using it, say, once... consider how much it annoys ME using it several thousand times.
Reasons to not have copy protection:
1) I hate it.
2) Our software gets cracked the day it comes out, and people are using cracked copies on the day of release ANYWAY.
3) It annoys the HELL out of users.
Reasons TO have copy protection:
1) It protects the investment of customers.
Unfortunately, as utterly bizarre as it sounds, that's a really strong reason.
If you're a customer, we have to put something in place which makes our software not free, because otherwise we're being disrespectful to you by asking you to pay for something which there are no restrictions to using free of charge.
Personally, I'd like to give stuff away free to everyone, but alas, I'm not naive enough to believe that I'd be able to go on doing that for very long before someone asked me for some rent, and I realised I was skint... the more money we make, the more plugins you get. [Or, in the case of recent history, the more mindblowingly groundbreaking a product you get...]
So in our case, you who pay for software invest in the future of that software... and for R&D that will give you more of that quality software that you love
So... our copy protection has a bit of an issue. In its eagerness to NOT annoy the user with windows telling you things like "err, hang on, you need to actually register this", after it has expired, it just locks itself into bypass [or won't pass audio]. So, when your 30days demo has expired, it doesn't tell you... it just stops working. To a legitimate user who didn't realise that they had to register it, after 30 days, our software appears to break!!! You open up your session and it just sounds different... and you wonder why!
We're thinking about how we can improve things. This issue of dilligence to protect investment means that we MUST do SOMETHING.
Currently, you go to the registration site, enter your details, and it sends you a license file
which will register your plugins and make them work forever. (though it has to be done manually)
We need to wire SOMETHING into the installer to sort this. But what if your studio computer ain't on the 'net?
Things we've been considering:
1) I got some speak'n'spell samples. I'm going to splice them up, a-la Cassetteboy, to say "Your Sonalksis
2) A BIG MESSAGE BOX TO TELL YOU THAT THEY HAVE EXPIRED AND WHAT YOU NEED TO DO TO REGISTER THEM.
3) A page in the installer that tells you ALL about registration (because you really care), or perhaps something that takes your details, and tries to connect to the 'net (or generates a link file if it can't?) and downloads+installs your license file.
4) A license manager application which is your friend.
Basically though, you know way more about this than we do, so we want you to know that we're taking it seriously, but really we want to know what you think.
Please tell us! I hate copy protection.
Dave.
Friday, August 11, 2006
DirectX Plugins
I don't want to write DirectX versions of TBK, 719, and the new stuff.
If you DO want me to, leave a comment and petition me!
Best of all, tell me what system you'd use them with!?
If you DO want me to, leave a comment and petition me!
Best of all, tell me what system you'd use them with!?
Thursday, August 10, 2006
Today, my brain hurts.
Heya,
Today has been.... eventful (read: painful).
Fixed a bug in the copy protection so that intel mac demos don't time out immediately.
Refactored TBK severely, so it's MUCH MUCH quicker to open the UI and to load.
Suddenly TBK crashes in protools on launch.
Uuuugh!
Poke around for an hour or two, and discover that I have (Very cleverly) left a directive in the build that it should use the instruction set and register set for the G5 only, for compiled code. I have no idea how. I didn't know that that setting existed. I'm using a macbook. It crashes. I remove the directive. It works. I curse, loudly, but feel better afterwards. :)
Killed the lovely nag screen when a plugin starts up.
Built all the plugins ready for beta.
At this point, I was ready to celebrate.
Until.
Someone *cough* decided that we should use this opportunity to check that the copy protection actually works, which is, unfortunately, fair enough.
Rebuild all plugins.
Then, beat up the installers (well, actually the mac one was fine, but the PC one needed kicking) to build TBK installers. Uuugh. If I'd put a few more hours in before, it'd have taken a few hours less.
I still haven't built that window that lets you choose -which- plugins get installed. Still on the list of things to do.
So, built em. Felt glad. Ready to celebrate. Headache in full swing by this point.
Recompilation sucks, because it takes a long time, and makes the computer very VERY hot.
I have a heatpad thing from the apple store. My laptop is cool, and comfy, all day. Except when it's doing heavy compiling. Then it melts my legs again.
I am using Parallels to run windows and compile for windows. I have to test stuff using bootcamp (because isochronous streaming to a virtualised os is mostly impossible), but it means i can compile win stuff, and check i haven't broken anything without rebooting.
Unless I leave XCode open, which eats ram. When both apps are running, my computer is essentially dead. It's a deeply frustrating experience. More RAM please! Anyone know if I can fit more than a gig in a macbook?
And now... we're going to beta -without- the installers, because we want to test them separately. Oh great. I'll do that tomorrow. Enough for today. Gah.
Feel free to post ibuprofen :)
Today has been.... eventful (read: painful).
Fixed a bug in the copy protection so that intel mac demos don't time out immediately.
Refactored TBK severely, so it's MUCH MUCH quicker to open the UI and to load.
Suddenly TBK crashes in protools on launch.
Uuuugh!
Poke around for an hour or two, and discover that I have (Very cleverly) left a directive in the build that it should use the instruction set and register set for the G5 only, for compiled code. I have no idea how. I didn't know that that setting existed. I'm using a macbook. It crashes. I remove the directive. It works. I curse, loudly, but feel better afterwards. :)
Killed the lovely nag screen when a plugin starts up.
Built all the plugins ready for beta.
At this point, I was ready to celebrate.
Until.
Someone *cough* decided that we should use this opportunity to check that the copy protection actually works, which is, unfortunately, fair enough.
Rebuild all plugins.
Then, beat up the installers (well, actually the mac one was fine, but the PC one needed kicking) to build TBK installers. Uuugh. If I'd put a few more hours in before, it'd have taken a few hours less.
I still haven't built that window that lets you choose -which- plugins get installed. Still on the list of things to do.
So, built em. Felt glad. Ready to celebrate. Headache in full swing by this point.
Recompilation sucks, because it takes a long time, and makes the computer very VERY hot.
I have a heatpad thing from the apple store. My laptop is cool, and comfy, all day. Except when it's doing heavy compiling. Then it melts my legs again.
I am using Parallels to run windows and compile for windows. I have to test stuff using bootcamp (because isochronous streaming to a virtualised os is mostly impossible), but it means i can compile win stuff, and check i haven't broken anything without rebooting.
Unless I leave XCode open, which eats ram. When both apps are running, my computer is essentially dead. It's a deeply frustrating experience. More RAM please! Anyone know if I can fit more than a gig in a macbook?
And now... we're going to beta -without- the installers, because we want to test them separately. Oh great. I'll do that tomorrow. Enough for today. Gah.
Feel free to post ibuprofen :)
Wednesday, August 09, 2006
BETA BEGINS!
Woohoo!
Well, it's taken a little longer than I'd have liked, 'cause we've had server nightmares [PLESK YOU ARE A CURSE!!], but everyone is signed up now, and I've sent the first email!
As I type this, FTP is getting sorted out [PLESK YOU REALLY ARE A CURSE], and the testers are starting to mail in info for our test grid database!
Woohoo!
I'll let you all know how it goes!
Dave.
Well, it's taken a little longer than I'd have liked, 'cause we've had server nightmares [PLESK YOU ARE A CURSE!!], but everyone is signed up now, and I've sent the first email!
As I type this, FTP is getting sorted out [PLESK YOU REALLY ARE A CURSE], and the testers are starting to mail in info for our test grid database!
Woohoo!
I'll let you all know how it goes!
Dave.
Saturday, August 05, 2006
Friday, August 04, 2006
Installers
So, I got the DirectX stuff building as part of the build, and everything is all tidy.
Which brings me to my next agenda point... Installers.
Now, InstallShield CAN be used in an automated build. Of this I am reassured...
I opened up InstallShield for the first time today, and my eyes BLED.
Wow.
So, I figured I had two options - 1- stick with InstallShield, deal with it, be a man.
or 2- move to inno setup.
In case you've never seen Inno Setup, it's amazing. It's hard to get excited about installers, to be honest, but Inno Setup is CLASS. That's the installer that makes installers that look like windows installers. ;)
And it's free!
So... our needs in the installer are pretty weird... no application to install... but installing four different sets of files, to four customizable locations... InstallShield does handle it very well... View: Old Installer:
This certainly does the job. But I don't want to use it because InstallShield is ugly confusing expensive and the sort of thing that makes me want to cry, since it is based around a database that they're quite happy for you to edit by hand and the files are binary and aaaaagh.
So Inno Setup uses scripts, and you can write bits of pascal, and customize it to hell, and basically anything remotely complicated you might want to do, they've already thought of, and given you a function call for.
This afternoon's work:
What do you think? Is it ok?
Dave.
Which brings me to my next agenda point... Installers.
Now, InstallShield CAN be used in an automated build. Of this I am reassured...
I opened up InstallShield for the first time today, and my eyes BLED.
Wow.
So, I figured I had two options - 1- stick with InstallShield, deal with it, be a man.
or 2- move to inno setup.
In case you've never seen Inno Setup, it's amazing. It's hard to get excited about installers, to be honest, but Inno Setup is CLASS. That's the installer that makes installers that look like windows installers. ;)
And it's free!
So... our needs in the installer are pretty weird... no application to install... but installing four different sets of files, to four customizable locations... InstallShield does handle it very well... View: Old Installer:
This certainly does the job. But I don't want to use it because InstallShield is ugly confusing expensive and the sort of thing that makes me want to cry, since it is based around a database that they're quite happy for you to edit by hand and the files are binary and aaaaagh.
So Inno Setup uses scripts, and you can write bits of pascal, and customize it to hell, and basically anything remotely complicated you might want to do, they've already thought of, and given you a function call for.
This afternoon's work:
What do you think? Is it ok?
Dave.
Ideas?
Hey,
You could post ideas for plugins on the forum, and they would filter their way to me in the same way that bug fixes and such do.
However, I'd like to invite you to tell me directly!
Please add comments to this post, and tell me what you'd like to see!
Feature requests, new plugins?
I'll be checking this blog every day, so you can be sure I'll read your comments.
Looking forward to your ideas... :-)
Dave.
You could post ideas for plugins on the forum, and they would filter their way to me in the same way that bug fixes and such do.
However, I'd like to invite you to tell me directly!
Please add comments to this post, and tell me what you'd like to see!
Feature requests, new plugins?
I'll be checking this blog every day, so you can be sure I'll read your comments.
Looking forward to your ideas... :-)
Dave.
And so it begins
I decided it'd be a good idea to start a development blog for Sonalksis projects.
This way, you guys can tell how things are progressing, and it saves me (a developer, rather than tech support) trying to read through the forum. Hopefully a big link to this is pasted somewhere on the forum so you will all know about it.
So... what IS news at camp Sonalksis?
Well, I saw one posting on the forum claiming that the two founders have new jobs now... wow... actually they've been immersed in some geniunely groundbreaking research for a few years now.
I've been brought to the team to take care of all the other 'little' things... like IntelMac (which is done now, and just needs testing), the RTAS versions of TBK (which are done, and again just need testing), and next is the 719 Gate, that just needs a little tidying.
Sorry you've not heard much from us, but now I have a blog so you can follow what I'm up to!
I'll try and post fairly regularly - every time I get to some milestone.
I can even use this as a way to share notes on the weird weird things that go on in plugin development!
So... let's start with some questions you'll probably be asking...
1) Why is this on blogger.com, and not on the sonalksis site?
Because blogger is really good, and I didn't want to have to add anything to the sonalksis site. I don't look after the site.
2) Who are you?
I'm Dave, I'm a software engineer - I used to work at Focusrite/Novation. A few things I've done include The Forte Suite for Protools, some MIDI drivers for some novation/digidesign units, was on the team for The Saffire Suite plugins, on the team for the Saffire range control panels, contributed some bits to the Liquid Channel... and TBK, which I hope you all like.
3) Will you let me be a beta tester?
No. I choose my beta testers - they're people I know and trust. Sorry; my beta list is like the A-Team. If you're hardcore enough, or prove yourself in some way, I'll come to you.
4) When can we see some stuff?!?!?!?!!?
Well, the email server blew up today, and it's getting fixed - hopefully as I type this.
Once that's done, someone will be setting up a mailing list for the beta testers, and we'll launch a load of stuff for beta... There's a new product finished too...
Basically, I've spent the past few weeks acclimatising myself to the way all the existing Sonalksis code works, and setting things up, like automated builds (This is important! see: The Joel Test ), and doing things like intel mac, and RTAS ports.
I've got to the end of that now, so it's time to test and release... and then the next major objective is the gate...
but before that...
*) Beta test everything
*) Get the DirectX plugins building automated
*) Maybe redo the installers to use the fantastic Inno Setup, which will work well with automation...
This way, you guys can tell how things are progressing, and it saves me (a developer, rather than tech support) trying to read through the forum. Hopefully a big link to this is pasted somewhere on the forum so you will all know about it.
So... what IS news at camp Sonalksis?
Well, I saw one posting on the forum claiming that the two founders have new jobs now... wow... actually they've been immersed in some geniunely groundbreaking research for a few years now.
I've been brought to the team to take care of all the other 'little' things... like IntelMac (which is done now, and just needs testing), the RTAS versions of TBK (which are done, and again just need testing), and next is the 719 Gate, that just needs a little tidying.
Sorry you've not heard much from us, but now I have a blog so you can follow what I'm up to!
I'll try and post fairly regularly - every time I get to some milestone.
I can even use this as a way to share notes on the weird weird things that go on in plugin development!
So... let's start with some questions you'll probably be asking...
1) Why is this on blogger.com, and not on the sonalksis site?
Because blogger is really good, and I didn't want to have to add anything to the sonalksis site. I don't look after the site.
2) Who are you?
I'm Dave, I'm a software engineer - I used to work at Focusrite/Novation. A few things I've done include The Forte Suite for Protools, some MIDI drivers for some novation/digidesign units, was on the team for The Saffire Suite plugins, on the team for the Saffire range control panels, contributed some bits to the Liquid Channel... and TBK, which I hope you all like.
3) Will you let me be a beta tester?
No. I choose my beta testers - they're people I know and trust. Sorry; my beta list is like the A-Team. If you're hardcore enough, or prove yourself in some way, I'll come to you.
4) When can we see some stuff?!?!?!?!!?
Well, the email server blew up today, and it's getting fixed - hopefully as I type this.
Once that's done, someone will be setting up a mailing list for the beta testers, and we'll launch a load of stuff for beta... There's a new product finished too...
Basically, I've spent the past few weeks acclimatising myself to the way all the existing Sonalksis code works, and setting things up, like automated builds (This is important! see: The Joel Test ), and doing things like intel mac, and RTAS ports.
I've got to the end of that now, so it's time to test and release... and then the next major objective is the gate...
but before that...
*) Beta test everything
*) Get the DirectX plugins building automated
*) Maybe redo the installers to use the fantastic Inno Setup, which will work well with automation...
Subscribe to:
Posts (Atom)
