I think adding Buzz machines support and calling Renoise Pro is not a good point.
A good point could be a Buzz plugin loader, able to be run from Renoise only, like in Fruity Loops.
Oskari’s license seems a little bit abusive. A single developer license will be enough for this case.
Another idea is making jeskola.net the place where to buy the renoise buzz machine loader.
HA! now everyone want ReNoise API, huh?!
you should have thought twice before voting DiskOp improvement!!!
While I understand the anger of Buzz plugin developers I must relate to similar thing that happened to GIF picture format compression licensing.
At these times people were angry for authors charging for these. Creating something for free and charging for it afterwards is not fair but is perfectly legal. But today nobody really cares about this and whoever needs GIF takes the extra-charged software and who doesn’t doesn’t do that.
We cannot go into illegal schemes. We also cannot make everybody happy.
Zephod: if you don’t want others to earn money on your plugins then know Oskari is already doing it by having Buzz support in Fruity Loops!
Please note: Fruity Loops is also having Buzz plugin support and I would really love to see all Buzz plugin developers going to their
web site and saying “hey Fruity, we don’t like your attitude for being open to Buzz and please now disable Buzz support”!
This is why we made a choice - Buzz version and Non-Buzz version. A “pro” name was just a proposal, don’t take it that seriously it can be easily changed and we also intended to do this by your request.
I say yes to both Buzz plugin support AND Renoise API. Buzz developers can eventually make Renoise port of Buzz plugins (and we won’t charge anything extra for it!)
Here is the bright side of this:
All Buzz plugin developers get an extra platform that can run their plug-ins. This increases popularity of their own plugins.
Fruity is not the only software using Buzz then (except Buzz itself).
Renoise is the only tracker (except Buzz) capable of supporting Buzz (i.e. having infrastructure set-up that is capable of supporting this). You won’t see this soon in other trackers very soon but if we put it in Renoise we’re probably able exit this “underground” domain where trackers are today (and we’d like to!)
If some Buzz plugin developer is so angry we can blacklist his plugin. Or… we can charge extra for it and give him the money? We believe that good work deserves to be paid for, but the choice on that is purely on Buzz plugin developer, he may choose it.
buzz plugin developers: you are the copyright owner of your plugins no matter if they are free or not. if you want to limit them to work only in buzz do it we’ll limit them out from renoise. But we don’t want this to be exclusive to Renoise, then you are supposed to do it for Fruity Loops too as well as other possible Buzz plugin supporters.
Final thought is: Renoise users that really want Buzz support will hate us for not giving them a choice. We cannot make everyone happy and no matter what we do there will be always someone complaining. If we don’t give them a choice Buzz plugin developers will be happy and Renoise users will be limited and will say things against us.
As Fruity already supports Buzz and it has been a fact for a quite a long time I really don’t see a bad thing in doing a Renoise support for it. Oskari already made much money in Fruity loops support…
so why the blame is on Renoise developers after all of that? Why not trying to post something on Fruity Loops forum and mailing Oskari instead and see their oppinions (or if they will care like we do?)
Buzzmachines would work just as good in Renoise…
Renoise is in fact just as modular as Buzz…
When I first started to look at Renoise I missed buzzmachines, but then I downloaded some free Vst-instruments. Now I don´t miss buzzmachines…
You dont see people who made free Vsti’s for Cubase complaining that another program can use them.
I can understand that people who make something for free don´t want others to earn money on them. But then you should talk to Oskari not the Renoise team!
@zephod:
I’m quite ignorant when it comes to this kind of things (standards in general 
).
Could you please enumerate some of these standards?
I don’t think they would be as powerful as a tracker API: such a solution would give us the complete control of the generator/effect:
you could assign a different behaviour to any pattern command for the plugin, exactly as it is for BUZZ, with the difference that ReNoise has a lot more built-in pattern commands.
You could also redefine any command behaviour: you could play a burp sample each time the user sends a 04xx command to your plugin, if you like this to happen (not a bad idea, huh? 
)
skip that buzz thing, please. I see some trouble coming up else.
why dont make something which is not a buzz-loader but instead make an API for renoise which does require very small changes to the source and a recompiling by the buzz-developer.
which means : you make kind of an emulator for buzz-machines, but which is not an emulator because original buzz-machines do not work.
they work only after the developer of a plugin does some small change (to the final output routine or whatever) and recompiles the source.
this solves two things : you are technically not using buzz-machines and only people who are interested in this recompile their machines for the renoise API (begging emails from renoise-users will surely help with that.)
this way we have the buzz-generator support and no developer feels ripped off and no one needs to pay extra money.
As long as Buzz machine devs are NOT allowed to make machines for money or at least to be free in deciding what do to with their machines (sell them, shareware, or free), supporting Buzz machines in any environment outside Buzz is equal to SLAVERY, and equal to THEFT.
Oskari has got everyone into this point. Oskari does not allow machine devs to charge money for their machines. I have said it before and I say it now - Oskari is the BIGGEST liability regarding Buzz.
Support Buzz machines in Renoise (and in Fruity lollipops for this matter), and you’ll be supporting THEFT as long as the machine devs are not free to decide how to sell their machines.
this looks to me like you wrote “code a Windows to work inside C-64”
Why not coding a buzz to work inside Renoise? 
I think Looza’s suggestion could be the best so far because it is mostly fair to us (we need more support) and to Buzz developer (they don’t wanna charge anything extra). I prefer to read suggestions rather than fight.
Too limeted? In wich way? Yes, you have probably not used renoise it much enough to realize how good it is 
The only thing people say is that they do not want renoise to support buzz
Personaly I think the VST-support in renoise is good enough, I do not realy see the point in any new developed Renoise API, but maybe I don’t realy see the avantage of new renoise API yet…
Did you know that you can change EVERY parameter in a VSTi from renoise (yes, with automation while playing)? Try *VSTAutomateDevice and bind it to the automation…
Renoise can already load FXP and FXB… even without a pro version
If you want a soft-sampler, why not buy a copy of NI Kontakt, it will take years for the renoise team to beat that soft-sampler, so I think it is better for the renoise-team to consentrate on other tasks… Maybe they can do changes to thir own RNI format, but to compete with Kontact as a softsampler doesn’t realy sound like the right way to go… renoise is in spite of it all a tracker/sequencer, not a softsampler… but, maybe I’m wrong, if it is easy, sure, let it be implemented, but I doubt it will be…
Personally I think it’s great with buzz support!
I don’t see why everyone thinks this is unfair. Oskari has developed a machine API which probably took lots of time. If he charges money for that it’s not that different from other software developers.
As for free machines, I’m not sure it’s legally possible for someone to say they don’t want their plugins to work in Renoise, unless stated in an agreement bundled with the machine. Although it might be more of a moral issue…
AFAIK buzz support is already implemented in Renoise, but was removed on request from Oskari. So the argument “I’d rather see DX/psychel/whatever support” is not really valid. I’d like to see that as well 
but considering the implementation work it might not be an option right now.
Just my 2 cents…
Realy, I think you should stick to the voiting results on the w.i.p page
… snippet from voting page
Buzz plugin support
Add Buzz support … (I’d pay extra for it) (12)
Add Buzz support … (I wouldn’t pay extra for it) (3)
Don’t bother with Buzz support! (73)
…
73 votes against 15
I doubt there would be any discussion if the renoise team anounced there won’t be any buzz support. Even some of the developers of buzzmachines seems to be pretty pissed.
And as Twilek mention there is VSTi support.
Simon:
The WIP pages say that 12 people will pay extra for Buzz support. If it’s very little work I think it’s justified.
This is a though one.
Nobody has to buy the Buzz version, but on the other hand some Buzz machine coders get upset when someone charge money for Buzz support…
Hmm I agree with looza.
If its not to hard make an API…Then when Renoise has lots of machines you could sell the rights to the API
An API is not a software. It is just a definition (an interface) how a software communicate with another software… An Application Program(ing) Interface that you program “agaist” when you do for example plugins…
The hard thing is NOT to define the API but to do the plugins that support the API…
Let us make a comparison:
Lets say you know a foreign language, say Chinese for example. It took you many hard years to learn this language but now you govern it very well. One day mr Bob will teach you that you actually can make some benefit of your knowledge if you will help his friends to speak Chinese. Of course you do it, and you do it for free cause you think it is fun. You realy enjoy to help people so you begin to think about to help other people who wants to learn Chinese, not just friends to Mr Bob… BUT before you even think about to start teaching other people Chinese then Mr Bob comes to you and wants to speak with you. He says “Just remember one thing, if you ever teach anybody else to speak Chinese, thouse people have to pay me some money if they want to use their knowledge in Chinese… Why? Because I was the one who teached you how to teach other people Chinese…”
Maybe not the best comparison, but now you maybe atleast see the unfair part of it…
It will be more legal to do that than to charge money for an api when the plugin-developers whant get a penny…
The thing is that 74 people voted for “Don’t bother with Buzz support!”. It were no option in the poll saying “Do absolutly NOT add buzz-support in any version of renoise”. If that option would have been available I would have definitly voted for that one, and I think more people than just me would have done the exact same thing… why? in my case becasue it is simply not moraly defensible agaist the buzz plugin developers…
Banner:
Say no to Buzz Suport now! Tomorrow it can be too late
twilek:
I know what an API is. Of course it took time to develop, even though it can’t be compared to the developing time of machines. If Oskari wants to charge people for his work he has the right to do so. Same goes for machine developers of course. Just because many persons write free machines (which we should be very grateful to imo) doesn’t mean Oskari is the devil for not developing for free.
If 12 persons register buzz version that means max $312 to Oskari which is not that much for his work that I think it’s immoral. That’s what I charge for 3 hours at work.
As the majority voted not to bother with buzz support you should stick to it. Why even bother putting a voting page up there if you do not listen to your users?
Rick
And about voting… You’re only guessing that many of the 74 persons against buzz support actually voted that way because they felt the way you do. Maybe you’re right… I don’t know.
If the vote would have included “I don’t care as long as it doesn’t affect other features” and “Ban buzz support” maybe it would be easier to decide what to do. I will respect whatever choice is made, but it would be nice to have buzz support and the argument that buzz support shouldn’t be included because Oskari is a prick seems like a stupid argument to me.
Rick:
If the WIP should be followed in all cases all the hard parts of cool features should be implemented. Isn’t it logical that the ratio how many are interested in contrast to the amount of work decides? And other factors such as time plan and which developer should implement it might be considered as well. I just believed that the Renoise team have thought about this… they have listened very much to the users so far at least.