Ervaringen Virus TI
- Thread starter avs
- Start date
Origineel geplaatst door Acidfever
Helemaal mee eens, maar goed dit ging over de virus dus laten we deze discussie maar niet voortzetten.
offtopic
ik ben het er niet mee eens... als je goed kan programmeren kan een het ene algoritme sneller zijn als het andere en toch hetzelfde doen... dus grote bull shit imho patatmet
Patat Met
TB or not TB
Kan je een paar voorbeelden geven?
Ik wil altijd leren.
Ik veronderstel dat DSP programmatie gebeurt aan de hand van een assembly taal?
Als dat het geval is dan kan je, zoals de meeste programmeertalen, in assembly op meerdere manieren een resultaat bereiken, maar de 1 "verprutst" meer cycli dan de andere.
(Tzou kunnen dat ik er flagrant naast zit hoor
)
Als dat het geval is dan kan je, zoals de meeste programmeertalen, in assembly op meerdere manieren een resultaat bereiken, maar de 1 "verprutst" meer cycli dan de andere.
(Tzou kunnen dat ik er flagrant naast zit hoor
)
Patat Met
TB or not TB
Nu moet ik je nog steeds op je woord geloven.
Heb je geen voorbeeld?
Heb je geen voorbeeld?
Patat Met
TB or not TB
Ik wil gewoon iets leren.
Doe nie zo vlauw, geef effe een voorbeeldje joh.
Als ik niets leer kan ik ook niet m'n mening veranderen.
En dan blijf ik denken dat je onzin verkoopt.
Doe nie zo vlauw, geef effe een voorbeeldje joh.
Als ik niets leer kan ik ook niet m'n mening veranderen.
En dan blijf ik denken dat je onzin verkoopt.
Het klopt toch wel wat vir over dat programmeren zegt hoor. Ik heb zelf geen ervaring met het coden van geluidsalgorithmen maar ik weet als informaticastudent uit eigen ervaring dat je een probleem (het te programmaren concept) op meerdere manieren kan oplossen.
Ik heb nou geen stukje code bij de hand en dit zou misschien wat ver gaan voor dit onderdeel van het forum (en al helemaal offtopic), maar in praktijk komt het er bijna altijd op neer dat het gaat om luiheid of "onvoldoende" logisch denken. Je zou een aantal berekeningen op een meer complexe, maar tevens vlugger te verwerken manier kunnen programmeren OF je kiest een langere omweg met meer tussenstappen en/of een andere aanpak. Zelfde uitkomst, maar neemt meer verwerkingstijd in beslag.
Nu, het stukje "zelfde uitkomst" is waar de meesten het opgeven. Zelfde uitkomst is zelfde uitkomst, toch? Het produceren van een geluid door een digitale synth neemt cpu in beslag. Indien je erg veel effecten e.d. gaat gebruiken komen er veel meer algorithmes bij kijken en indien een hoop "omwegalgorithmen" bij elkaar komen gaat dat onnodig CPU vreten.
Correct me if I'm wrong...
Ik heb nou geen stukje code bij de hand en dit zou misschien wat ver gaan voor dit onderdeel van het forum (en al helemaal offtopic), maar in praktijk komt het er bijna altijd op neer dat het gaat om luiheid of "onvoldoende" logisch denken. Je zou een aantal berekeningen op een meer complexe, maar tevens vlugger te verwerken manier kunnen programmeren OF je kiest een langere omweg met meer tussenstappen en/of een andere aanpak. Zelfde uitkomst, maar neemt meer verwerkingstijd in beslag.
Nu, het stukje "zelfde uitkomst" is waar de meesten het opgeven. Zelfde uitkomst is zelfde uitkomst, toch? Het produceren van een geluid door een digitale synth neemt cpu in beslag. Indien je erg veel effecten e.d. gaat gebruiken komen er veel meer algorithmes bij kijken en indien een hoop "omwegalgorithmen" bij elkaar komen gaat dat onnodig CPU vreten.
Correct me if I'm wrong...
Patat Met
TB or not TB
Als een fabrikant niet slim genoeg is om effectieve algoritmes te gebruiken, is ie toch zo bankroet.
Ik denk nog steeds niet dat er veel verschil in zal zitten.
Maar ik wil wel graag van mening veranderen.
Ik denk nog steeds niet dat er veel verschil in zal zitten.
Maar ik wil wel graag van mening veranderen.
Patat Met
TB or not TB
Bij Clavia toch idem dito.
koekebakker
Olie op het vuur
Ik wil hier wel even op inhaken.
Ik ben het zeker met virkaz eens. Gezien een CPU/DSP niet veel meer in huis
heeft dan optellen, aftrekken en geheugen + dma aanspreken en schrijven is het
toch aan de programmeur hoe je het gebruikt.
Voorbeeldje: laat een cpu 10 + 10 uirekenen. (in assembly natuurlijk)
De programmeur kan zorgen dat de cpu 2+2+2+2+2+2+2+2+2+2 uitrekent,
maar ook 10+10 ineens. Vergis je niet, maar sommige cpu's zijn sneller met het
betrekenen van 2+2+2+2etc, dan 10+10
koekebakker
Olie op het vuur
Nu het toch over de TI gaat
Ben ik de enige waarbij een delay altijd naar beneden pitcht? (delays worden vals :/ )
Dit ervaar ik met alle patches (ook rom) waarbij delay gebruikt wordt.
Ben ik de enige waarbij een delay altijd naar beneden pitcht? (delays worden vals :/ )
Dit ervaar ik met alle patches (ook rom) waarbij delay gebruikt wordt.
koekebakker
Olie op het vuur
dat gaat in dit geval vrees ik niet op. Audio komt door S/PDIF, en de midi heb ik ook maar
even gestest met midi kabels (USB losgekoppelt)
Leuk dingetje voor OS 1.2
even gestest met midi kabels (USB losgekoppelt)
Leuk dingetje voor OS 1.2
anoniempje
hobby knooier
- Lid sinds
- 30 september 2003
- Berichten
- 4.897
volgens mij heb je dan iets in de trent van delay dynamics/tune aanstaan ik weet zo uit m,n hoofd niet welke synthesizer dit 100 procent zeker heeft maar misschien/waarschijnlijk zit het op de TI
Acidfever
There's no "I" in denial.
- Lid sinds
- 12 Maart 2004
- Berichten
- 9.068
Een goed voorbeeld van effectief gebruik maken van DSP power is het hele hyper/supersaw gebeuren. Denk je echt dat in een hypersaw algoritme alle 9 OSC's apart worden berekend?
In een G2 kun je wel 200+ OSCS simuleren door gebruik te maken van simpele delay modules en de output van deze modules ten opzichte van elkaar te detunen. Daarmee creeer je met zeer weinig middelen zeer dikke sounds die zeer weinig DSP power kosten. Dit kost je bijvoorbeeld net 40% DSP power op 1 slot terwijl je toch eventjes 200 ocs's aan geluidopwekking hebt. Dit soort truukjes worden veelvuldig gebruikt. Grappige ervan is dat je dit in een G2 op elke audiobron kunt toepassen, niet alleen op de oscillatoren.
Klinkt met 200 Oscs overigens nergen naar.....geitenbrij......maar beperk je dit aantal kun je er erg interessante dingen mee doen. Hypersaw,hypersine, hypersquare maar ook hyperfilter, hyperdistortion you name it.
Het gaat niet zozeer om sneller maar om wat je precies uithaalt. Een Virus heeft zover ik weet tot en met de C serie gewoon dezelfde DSP aan boord welke gewoon ietsje hoger geklokt worden bij elke nieuwe serie.
De TI heeft er 2 aan boord om ook de FX per part e.d. te kunnen faciliteren. De ruimte die zo wordt gecreeerd op de eerste DSP kan zo worden ingezet voor voices, maar dat kunnen er nooit opeens 58 meer zijn. Dus wordt er gebruikt gemaakt van bepaalde truukjes. Niets mis mee hoor....maar ook geen rocketscience. Gewoon slimmer gebruik maken van de beschikbare DSP power.
Wel jammer dat dan de overige features (die wel echt nieuw zijn) erg matig worden geimplementeerd.
In een G2 kun je wel 200+ OSCS simuleren door gebruik te maken van simpele delay modules en de output van deze modules ten opzichte van elkaar te detunen. Daarmee creeer je met zeer weinig middelen zeer dikke sounds die zeer weinig DSP power kosten. Dit kost je bijvoorbeeld net 40% DSP power op 1 slot terwijl je toch eventjes 200 ocs's aan geluidopwekking hebt. Dit soort truukjes worden veelvuldig gebruikt. Grappige ervan is dat je dit in een G2 op elke audiobron kunt toepassen, niet alleen op de oscillatoren.
Klinkt met 200 Oscs overigens nergen naar.....geitenbrij......maar beperk je dit aantal kun je er erg interessante dingen mee doen. Hypersaw,hypersine, hypersquare maar ook hyperfilter, hyperdistortion you name it.
Het gaat niet zozeer om sneller maar om wat je precies uithaalt. Een Virus heeft zover ik weet tot en met de C serie gewoon dezelfde DSP aan boord welke gewoon ietsje hoger geklokt worden bij elke nieuwe serie.
De TI heeft er 2 aan boord om ook de FX per part e.d. te kunnen faciliteren. De ruimte die zo wordt gecreeerd op de eerste DSP kan zo worden ingezet voor voices, maar dat kunnen er nooit opeens 58 meer zijn. Dus wordt er gebruikt gemaakt van bepaalde truukjes. Niets mis mee hoor....maar ook geen rocketscience. Gewoon slimmer gebruik maken van de beschikbare DSP power.
Wel jammer dat dan de overige features (die wel echt nieuw zijn) erg matig worden geimplementeerd.
je ziet dat vaak aan het einde van een traject de code door een andere progger wordt bekeken (a la XP programmeren) en dat die er nog schoonheidsfoutjes uit haalt. en waar mensen werken worden fouten gemaakt.
waarom dacht je dat testen zo hot is op moment... omdat er vroeger heel veel projecten zijn mislukt door te laat of door niet onafhankelijk te laten testen...
maar ik heb alleen gezegd dat de cpu er geen bal mee te maken heeft en dat gaf je in je 1e antwoord ook al aan ("indirect") dus einde discussie lijkt me. het ging in feite ook niet om prog trucjes, maar om het bovengenoemde.
een een sukkel van een programmeur kan op een super dsp nog wel een redelijke synth neerzetten.
maar een topprogger kan op een simpel dsptje al een vette osc bouwen.
dus kracht bepaalt wel hoeveel je van iets kan, maar dat zegt toch niet perse iets over de kwaliteit?
ik d8 dat je dat zelf nu wel de conclusie zou kunnen trekken.
enfin... ontopic weer heren:
jammer van xs dat de ti zo klote draait. ik blijf eerst nog bij de c (zei ik 2 jaar geleden al en heb geen spijt) en check later wel of ie er eens komt.. eerst maar bugvrij.. (typisch geval van niet testen en verkeerde planning!)
Laatst gewijzigd:
