Är det värt att köpa istället för att ladda ner?

[MassiveWave]

Ilok är skitbra. På vilket sätt är en ilok ett hån?Att man slipper hålla på med hämta hem ny licens och allt annat strul? Är en dongel också ett hån mot alla cubaseägare?

Det står jag fast vid. Att hämta en licens per installation (kör både stationärt och bärbart) gör jag en gång per burk och sen behöver jag inte tänka mer på det. Plus att jag vill hålla det så cleant som möjligt med extra prylar från min bärbara när jag är på resande fot. NI har dessutom fått ordning på sitt servicecenter så det funkar skitsmidigt att regga produkterna även en andra gång.

Men framför allt ogillar jag att när man har lagt en jäkla massa pengar på ny mjukvara tvingas koppla in en helt poänglös hårdvara (dvs inget som avlastar datorn) och om man tankar så slipper man.

I fallet Cubase kan detta vara löst för länge sen men iLok dongeln ska enligt många dragit ner prestandan rätt bra, de med crackade versionen hade runt 20% bättre prestanda vilket är helt upp och ner ifall det stämmer.

[DMM]

I fallet Cubase kan detta vara löst för länge sen men iLok dongeln ska enligt många dragit ner prestandan rätt bra, de med crackade versionen hade runt 20% bättre prestanda vilket är helt upp och ner ifall det stämmer.

Nu ska jag inte öppna dörrar till det "crackade" landet.

Om Ni är bekanta med gruppen "H2O" - "Try before by" etc... så har dom mer eller mindre bevisat att Steinbergs "copy protection" anropas löpande. Jag kommer inte exakt ihåg hur hög procenten var på hur mycket dessa "calls" drog ned prestandan, men jag har för mig att det rörde sig om över 50 procent, löpande, men inte stadigt. Ibland mindre, ibland mer.

Så fort man t.ex. flyttade en midinot så gjordes ett antal "calls" till "Dongle".... Vid uppstart, vid playback, vid record etc. utföres dessa calls, som dessutom blir än fler och värre då de försöker stoppa dessa grupper som "crackar" mjukvara. VIPS så blir programvaran sämre av piratkopiering...

Att Steinberg väljer att själva radera information gällande detta från deras egna forum gör ju inte saken bättre.

Jag är dock inte intresserad av detta då iLok, för min del, aldrig ställt till med prestandaproblem, och ej heller "crashar" eller buggar ur. Det har aldrig hänt under flera års användande.

Jag kan dock förstå om någon på laglig väg införskaffar t.ex. Cubase, och sedan laddar ner en "dongle crack" istället för att köra sin medföljande "dongle" för att få bättre prestanda. Om så är fallet har inte Steinberg lyckats speciellt bra med sitt kopieringsskydd.

[joachime]

Om Ni är bekanta med gruppen "H2O" - "Try before by" etc... så har dom mer eller mindre bevisat att Steinbergs "copy protection" anropas löpande. Jag kommer inte exakt ihåg hur hög procenten var på hur mycket dessa "calls" drog ned prestandan, men jag har för mig att det rörde sig om över 50 procent, löpande, men inte stadigt. Ibland mindre, ibland mer.

Om du vore bekant med Cubase skulle du veta att det där är en myt.

[DMM]

Om du vore bekant med Cubase skulle du veta att det där är en myt.

Du tar för givet att jag inte är bekant med Cubase (för din vetskap började jag med Notator/WaveLab/Cubase när de såg dagens ljus.

Jag har till och med haft ett möte med Steinberg angående utveckling av mjukvara).

Du tar för givet att jag inte varit i kontakt med H2O och deras arbete genom att påstå att det är en myt.

Men det är ok, för som jag skrev så vill jag inte öppna några dörrar till "crack"-landet. Jag anser det vara fel.

Jag ska inte föreslå något, och inte heller berätta om detta för det kan uppfattas fel, men för de som läser här finns "Google" för de som är händiga på att korrekt söka info.

[joachime]

Sedan jag skrev förra inlägget har jag låtit Cubase 4 rulla utan dongle. Jag har spelat in ljud, jag har spelat upp ljud och jag har sparat utan att programmet klagat om donglens frånvaro. Tretton minuter utan anrop.

Edit: Förlåt, sjutton minuter and counting ...

Redigerat 14 februari 2013 av joachime

[joachime]

Slängde på två ilok-pluggar för skojs skull. De krävde dongle för att öppnas (även Cubase passade på att be om dongle bär jag öppnade dom). När pluggarna laddat ryckte jag både syncrosoft- och ilok-stickorna och tryckte play. Det rullar på utan problem.

[DMM]

Slängde på två ilok-pluggar för skojs skull. De krävde dongle för att öppnas (även Cubase passade på att be om dongle bär jag öppnade dom). När pluggarna laddat ryckte jag både syncrosoft- och ilok-stickorna och tryckte play. Det rullar på utan problem.

Kan hända att min information gällande detta är något äldre. Jag tror det var Cubase XL... eller vad det nu hette då... kan det stämma?

[joachime]

När jag ändå var i farten slängde jag även på en wavesplugg som licensieras via WLC (ytterligare ett dongleformat). Den gjorde anrop när pluggen skulle ladda (däremot inte cubase den här gången). När den laddat ryckte jag även den dongeln och rullade igång igen utan problem.

[joachime]

Kan hända att min information gällande detta är något äldre. Jag tror det var Cubase XL... eller vad det nu hette då... kan det stämma?

Jag trodde du var bekant med Cubase. 😉

Cubase SX lanserades 2002 och senaste versionen släpptes 2005.

Jag gjorde även ett test med Cubase SX 2 på den tiden med liknande resultat.

[DMM]

När jag ändå var i farten slängde jag även på en wavesplugg som licensieras via WLC (ytterligare ett dongleformat). Den gjorde anrop när pluggen skulle ladda (däremot inte cubase den här gången). När den laddat ryckte jag även den dongeln och rullade igång igen utan problem.

iLok har jag dock inget att klaga på. Jag är helnöjd med den. Och kan hända de nyare versionerna Cubase etc. har blivit bättre?!...

[DMM]

Jag trodde du var bekant med Cubase. 😉

Cubase SX lanserades 2002 och senaste versionen släpptes 2005.

Jag gjorde även ett test med Cubase SX 2 på den tiden med liknande resultat.

Inte nu längre, haha... Har lämnat Cubase bakom mig för ProTools, för rätt så länge sedan.

Detta innebär att du måste ha läst H2O och deras "rapporter" där dom bevisade uttryckligt i

programmeringskoden (debuggat etc.) hur många calls som utfördes löpande.

Jag minns däremot inte om det slutade att fungera, som du skriver, eller om det bara var

prestandasänkande överlag!?...

Hade jag haft kvar "rapporterna" hade jag kunnat visa dom.

[joachime]

iLok har jag dock inget att klaga på. Jag är helnöjd med den.

I och med att du hakade på inlägget om att ilok belastar processorn såg det ut så.

Och kan hända de nyare versionerna Cubase etc. har blivit bättre?!...

Nyare än 2002? Det var i så fall på printerportnycklarnas tid. 😉

[joachime]

Detta innebär att du måste ha läst H2O och deras "rapporter" där dom bevisade uttryckligt i

programmeringskoden (debuggat etc.) hur många calls som utfördes löpande.

Anrop till vad? Inte dongeln i alla fall.

[joachime]

BTW. Cubase (med aktiva ilok- och wlc-pluggar) har nu rullat på i en halvtimme utan några anrop till donglar. Bortsett från dom gångar jag laddat nya pluggar till projektet. Tror jag avslutar experimentet nu.

Edit: Jag stannade uppspelning, sparade och stängde projektet och avslutade sedan programmet utan några anrop till någon av nycklarna.

Redigerat 14 februari 2013 av joachime

[DMM]

BTW. Cubase (med aktiva ilok- och wlc-pluggar) har nu rullat på i en halvtimme utan några anrop till donglar. Bortsett från dom gångar jag laddat nya pluggar till projektet. Tror jag avslutar experimentet nu.

Edit: Jag stannade uppspelning, sparade och stängde projektet och avslutade sedan programmet utan några anrop till någon av nycklarna.

Haha, fantastiskt!

Ja, avsluta experimentet du 🙂

Om jag hittar, eller lyckas komma över de "rapporter" jag talar om så ska du få dom, det lovar jag 🙂

[Bullerbyn]

Nu ska jag inte öppna dörrar till det "crackade" landet.

Om Ni är bekanta med gruppen "H2O" - "Try before by" etc... så har dom mer eller mindre bevisat att Steinbergs "copy protection" anropas löpande. Jag kommer inte exakt ihåg hur hög procenten var på hur mycket dessa "calls" drog ned prestandan, men jag har för mig att det rörde sig om över 50 procent, löpande, men inte stadigt. Ibland mindre, ibland mer.

Så fort man t.ex. flyttade en midinot så gjordes ett antal "calls" till "Dongle".... Vid uppstart, vid playback, vid record etc. utföres dessa calls, som dessutom blir än fler och värre då de försöker stoppa dessa grupper som "crackar" mjukvara. VIPS så blir programvaran sämre av piratkopiering...

Att Steinberg väljer att själva radera information gällande detta från deras egna forum gör ju inte saken bättre.

Jag är dock inte intresserad av detta då iLok, för min del, aldrig ställt till med prestandaproblem, och ej heller "crashar" eller buggar ur. Det har aldrig hänt under flera års användande.

Jag kan dock förstå om någon på laglig väg införskaffar t.ex. Cubase, och sedan laddar ner en "dongle crack" istället för att köra sin medföljande "dongle" för att få bättre prestanda. Om så är fallet har inte Steinberg lyckats speciellt bra med sitt kopieringsskydd.

Tycker detta låter ytterst konstigt då vår lagliga version av Cubase uppvisat betydligt stabilare beteende än någon av de crackade varianter jag testat. Har man dessutom så enorma problem med prestanda så kanske man först och främst fixar en värre dator?

[Izy]

den här tråden e ett gtd självmord. självklart finns det extremt många här på forumet som har hemtankade pluggar o dylikt, men dom kommer aldrig vilja yttra sig i en sån här tråd så det är skott mot ett mål

[Claes Holmerup]

Som Joachime säger, så är det en gammal seglivad myt som troligen har spridits för att motivera folk att ge H2O extra beröm. Det har aldrig varit så illa som det hävdas, utan dongle-anropen sker aldrig under tidskritiska tillfällen och segar därför inte ner ett dugg.

Det är kanske så att dongle-anropen är väldigt intensiva vid vissa icke-tidskritiska tillfällen, men definitivt inte under drift.

[DMM]

Tycker detta låter ytterst konstigt då vår lagliga version av Cubase uppvisat betydligt stabilare beteende än någon av de crackade varianter jag testat. Har man dessutom så enorma problem med prestanda så kanske man först och främst fixar en värre dator?

Håller med fullständigt!

Tror jag skrev det tidigare någonstans, att "crackade" program oftast innehåller mycket buggar.

Japp. Har man problem med prestanda så är det bara att uppgradera. Igen, håller med!

[Bullerbyn]

Sen är det ju skönt att man har support. Visserligen har jag inte använt mig av support sedan Mi7 stod för supporten, tror dessutom att vi körde SX2 sist jag behövde hjälp av support, det var ju ett tag sedan. Nu har jag inte en aning vart man vänder sig om man behöver hjälp? Å snart ska man uppgradera till 7:an.

Redigerat 14 februari 2013 av Bullerbyn

[Claes Holmerup]

Sen är det ju skönt att man har support. Visserligen har jag inte använt mig av support sedan Mi7 stod för supporten, tror dessutom att vi körde SX2 sist jag behövde hjälp av support, det var ju ett tag sedan. Nu har jag inte en aning vart man vänder sig om man behöver hjälp? Å snart ska man uppgradera till 7:an.

Då ringer man Emil (som jobbade hos MI7 tidigare), som har hand om den skandinaviska Steinberg-supporten. Han är en klippa! 🙂

http://www.steinberg.net/en/support/support_contact/scandinavia_english.html

[Bullerbyn]

Då ringer man Emil (som jobbade hos MI7 tidigare), som har hand om den skandinaviska Steinberg-supporten. Han är en klippa! 🙂

http://www.steinberg...ia_english.html

Aha! Va bra då vet man det också! Tackar!

[MRS8]

Har ingen dongel till mitt cubase 6 elements, behöver inte ha internet igång men efter någon dag vill den att jag kopplar upp mej. Är det bara elements som har det så ?

försökte mej på att lägga in demon på halion 4 igår men den 32 siffriga koden gick inte att ansluta utan dongel 🙁

(får väl köpa den direkt då!)

[Signia]

Detta innebär att du måste ha läst H2O och deras "rapporter" där dom bevisade uttryckligt i

programmeringskoden (debuggat etc.) hur många calls som utfördes löpande.

Hade jag haft kvar "rapporterna" hade jag kunnat visa dom.

Ja dom vore otroligt intressanta att se.

Enda jag har hört om är readme-filen för crackade cubase SX3, där H20 påstår detta, i ett par stycken text. Den texten är nog inte så svår att få tag på.

Men gjorde H20 grupperingen några uttryckligen bevisande rapporter (alltså flera) med kod-exempel? så vore dessa otroligt intressanta att se, för alla. Är jag helt övertygad om.

EDIT: Hittade H20 readme texten på nätet, där dom påstår detta. Men hur många calls som utförs löpande påvisas inte.

Note to protection coders :

Unbelievable way you transform an application. We estimate that

between 30% & 40% of the application are wrapped in the script

protection. Protection is one thing but this surely effects an

application performance. You probably could get a performance gain of

50% without the protection!!

Think about this : Once broken, the protection is , what ????

PS1:

Note to Steinberg/End-Users:

It seems that our prior Release Note stirred something in the

Audio Community (Yes, we can read). To get some of the facts

straight we're going to reveal some secrets about the copy

protection itself, and why we stated that it severely impacts

performance.

Info from Syncrosoft website:

"Syncrosoft's protection solution is different from

mainstream software copy protection methods. It is based on a

secure executer, the eLicenser, and the patented MCFACT

technology" "At runtime, the transformed program code does not

reveal its semantics. The eLicenser's crypto-services are called

from time to time by the transformed program code." The

transformed program code is represented as tables in the computers

memory. An adversary can not reverse-engineer or debug the tables,

because a reverse transformation from the tables to original

program code is not feasible. If the tables are manipulated, the

transformed program code will crash or produce invalid results."

So its not crackable?...

Now here is the explanation for what really goes on:

around 25% of the program code is MCFACT protected and therefore

protection-related.

Transformation is based on replacing ordinary machine code into

tables representing results from calculations

Example:

Adding 2 numbers Normal machine-code would look something like :

Add eax, ebx

This will take 1 CPU cycle to execute.

Now comes MCFACT :

1) Transform the first number into a table

2) Transform the second number into a table

3) Do allot of manipulation of these tables

4) More manipulation

5) Transform the Tables back to the numbers

6) Add the 2 numbers

This entire piece takes up hundreds of machine code lines and a

lot of loops inside this code...estimated CPU-cycles <insert

number greater than 1 here>

No performance loss? We don't think so..........

And this code runs all the time!!......The dongle in fact is only

called 1 out of 10 times inside these scripts.........

A good example is the protection build in the midi-part. This is

entirely wrapped in the script-crap. Try moving a note and swirl

it around.....you should notice a sluggishness in the movement.

In fact u will notice an improvement in version 3.1 prior to the

3.0 release. This is not due to improvements made by Steinberg

(the midi-engine is still the same) but improvements made by

Syncrosoft! (They optimized the script engine)!!!!!!!

To give the end user some peace of mind: the scripts aren't built

into the real-time audio-engine.....this is impossible because of

the performance loss u would have from the MCFACT.

Redigerat 14 februari 2013 av Signia

[Terror]

Jag tappade min banan på golvet nyss.

[oakleaf (oregistrerad)]

Jag tappade min banan på golvet nyss.

Hoppas innerligen att du tyckte det var vaert att koepa bananen...

[joachime]

Note to protection coders :

Unbelievable way you transform an application. We estimate that between 30% & 40% of the application are wrapped in the script protection. Protection is one thing but this surely effects an application performance. You probably could get a performance gain of 50% without the protection!

Ställer mig undrande till det påståendet. Om vi utgår från att senare versioner av Cubase är skrivna på liknande sätt (programmet använder fortfarande samma kopieringsskydd) skulle det i så fall innebära att en renare optimal VST-host skulle prestera ungefär 50 % mer än Cubase. Det är inget jag har märkt av.

Skulle vilja vända på det och påstå att den som omsorgsfullt plockade bort kopieringsskyddet från programmet förmodligen visste en hel del om den delen av programmering men inte så mycket om utveckling av musikprogram. Det är alltså en lekmans gissning, precis som min.

To give the end user some peace of mind: the scripts aren't built into the real-time audio-engine.....this is impossible because of the performance loss u would have from the MCFACT.

Så realtidsprocesserna anropar alltså inte dongeln, vilket även mitt experiment igår visade. Och det är ju vid de tillfällen som ett musikprogram tar resurser i anspråk.

[DMM]

Hoppar in med en låååååång tråd här, från Cubase.net, som kanske kan vara intressant.

http://cubase.de/phpbb2/viewtopic.php?t=59427&postdays=0&postorder=asc&start=0&sid=e11434f711db04002ab949eeac29d7b6

[DMM]

Sen kanske detta svar är av intresse från Steinberg själva:

Posted: Sat Nov 01, 2008 1:36 am Post subject: Hello,

Code: This tells me that there are dongle calls when creating audio tracks, tho I can't explain why you are able to create numerous audio tracks with no dongle before it realizes that there is in fact no dongle.

To have some "random" things is part of the protection. That you remove the dongle during operation is your own risc. We recommend to keep the dongle connected when you are working with Cubase.

 

Gr,

 

Chris

_________________

Steinberg Tech Support

Hmmm.... "Random things"????

Redigerat 15 februari 2013 av DMM

[DMM]

Sprang även på detta, också från Cubase.net:

Paul Woodlock

Guest

Posted: Sun Nov 02, 2008 12:39 am Post subject: Beryliam wrote:

Responsiveness is more affected by system instabilities than about a million dongle calls.

Not true in the slightest.

Quote:

The old dongle call myth was usually an exploityation (sic, I quite like it and will pass it on to GWB) by people trying to mitigate pirates by saying that the dongle-free illegals were faster.

The dongle call situation is/was NOT a myth.

Quote:

By a mallymillymollysecond maybe but the lemmings love all that rebel nonsense so they went over the cliff with it. If one had a 10 second delay then you needed to buy a new computer not get Steinberg to guess what program calls might put a plaster on it for a while. The same people who had the 10 second delays were probably of the continually moaning WTF!?ers who chime in every other week with some imagined bug or other.

The unresponsiveness was NOTHING to do with the spec of the computer it was to do with the implementation of the copy protection into various functions such as re-routing busses - adding/removing plugins - creating new tracks - deleting tracks - changing ASIO buffer size/etc/etc

 

Sometimes thousands of dongle calls were generated and for reasons only known to steinberg/syncrosoft the complexity of the project made a difference to the number of dongle calls and thus the response times. And not everyone was affected by the dongle calls in the same way either.

 

Oh and Steinberg know all about the dongle call situation and have largely resolved it from Cubase 4.1 onwards. It's been an ongoing problem since Cubase SX2 Back to top

Paul Woodlock

Guest

<a href="http://www.cubase.net/phpbb2/viewtopic.php?p=792346#792346" style="color: rgb(40, 59, 77); ">Posted: Sun Nov 02, 2008 12:48 am Post subject: A Smith wrote: There are dongle calls being made all the time.

That's not true. The amount of dongle calls and what functions triggered the dongle calls has varied with each version of cubase. The more dongle calls the less responsive the affected functions have been.

 

And the type of dongle make a difference as well. the very first dongles that came with Cubase SX1 , the longer type are slower than than the newer shorter versions. After I discovered this Steinberg have added a page in their knowledge base about it.

 

But it's important to remember than not everyone is affected by it and there's a few variables, such as dongle type. Hardware combination and project complexity than can affect the responsiveness of those affected.