artists-choice
Ouwe rot
hmmzzzz ik w8 liever ff af, dit heb ik al eerder gehoord.....
Virus TI vertraagd + reviews?
- Thread starter Thoraval
- Start date
MikeJarod
ziet ze vliegen
- Lid sinds
- 3 december 2003
- Berichten
- 1.468
Ik was het wachten op de TI meer dan beu dus heb van het weekend een 2e hands C aangeschaft. Ik laat m'n bestelling wel gewoon lopen, en zodra de TI leverbaar is verkoop ik m'n C gewoon weer. De prijs van de C was 850, dus tegen de tijd dat de TI komt kan ik 'm vast nog wel kwijt voor die prijs (of misschien wel meer).
Eerste indruk is heel goed, erg fijne, dikke en inspirerende sounds. Dit is m'n eerste Access voor het geval dat nog niet duidelijk was
Waar ik wel wat moeite mee heb zijn de FX. Als ik door de presets loop te scrollen in Single Mode dan heb ik vaak zoiets van 'zozo deze sound is vet, die noteer ik even en ga ik straks mee aan de slag'. Maar vaak als ik die sound dan in Multi Single mode oproep is ie een stuk minder, door de reverb/delay die ontbreekt. Dan stel ik deze in zoals gewenst, maar dan moet de volgende sound op een ander kanaal dezelfde reverb/delay gebruiken. En vaak komen de sounds dan niet zo naar voren zoals in Single mode.
Misschien ben ik verwend, want ik was een Novation Nova (onafhankelijke fx per part) en VSTi's gewend (FX tot je erbij neervalt). Dus ik vind dit af en toe wel een beetje onhandig bij de C. Of zie ik iets bij de C over het hoofd?
Nu zal de TI onafhankelijke reverb/delay per part hebben (de overige effecten zijn natuurlijk al onafhankelijk), maar heel weinig mensen in dit draadje zien dit volgens mij als meerwaarde? De meeste mensen lijken zich te focussen op de plugin, en hoeveel streams die zou moeten kunnen doorgeven. Dat vind ik een beetje raar.
Zijn de eigenaars van een C hier nou gewoon gewend aan 1 global reverb/delay of zien jullie wel degelijk meerwaarde in de onafhankelijke FX van de TI?
Eerste indruk is heel goed, erg fijne, dikke en inspirerende sounds. Dit is m'n eerste Access voor het geval dat nog niet duidelijk was
Waar ik wel wat moeite mee heb zijn de FX. Als ik door de presets loop te scrollen in Single Mode dan heb ik vaak zoiets van 'zozo deze sound is vet, die noteer ik even en ga ik straks mee aan de slag'. Maar vaak als ik die sound dan in Multi Single mode oproep is ie een stuk minder, door de reverb/delay die ontbreekt. Dan stel ik deze in zoals gewenst, maar dan moet de volgende sound op een ander kanaal dezelfde reverb/delay gebruiken. En vaak komen de sounds dan niet zo naar voren zoals in Single mode.
Misschien ben ik verwend, want ik was een Novation Nova (onafhankelijke fx per part) en VSTi's gewend (FX tot je erbij neervalt). Dus ik vind dit af en toe wel een beetje onhandig bij de C. Of zie ik iets bij de C over het hoofd?
Nu zal de TI onafhankelijke reverb/delay per part hebben (de overige effecten zijn natuurlijk al onafhankelijk), maar heel weinig mensen in dit draadje zien dit volgens mij als meerwaarde? De meeste mensen lijken zich te focussen op de plugin, en hoeveel streams die zou moeten kunnen doorgeven. Dat vind ik een beetje raar.
Zijn de eigenaars van een C hier nou gewoon gewend aan 1 global reverb/delay of zien jullie wel degelijk meerwaarde in de onafhankelijke FX van de TI?
SpaceAgent202
Sinds 2001
mijn korte mening
virus c is ranzig vet. globale delays of reverbs inderdaad lastig soms (maar soms ook weer makkelijk)
virus ti... evenzo ranzig vet. fx per part belangrijk. plugin interesseert me 0.
virus c is ranzig vet. globale delays of reverbs inderdaad lastig soms (maar soms ook weer makkelijk)
virus ti... evenzo ranzig vet. fx per part belangrijk. plugin interesseert me 0.
Acidfever
There's no "I" in denial.
- Lid sinds
- 12 Maart 2004
- Berichten
- 9.055
Ik gebruik de globale FX niet zo vaak. Overigens gebruik ik vaak de fx op 1 of maximaal 2 geluiden en process ik de rest outboard (heb je ook nog wat aan je outputs). Outboard reverb domineert toch behoorlijk over de reverb van de C.
Een C + medium reverb module lijkt me sowieso een betere optie dan een Ti met FX per part. Al is het natuurlijk wel gewoon handig om FX per part te hebben. Vooral delay. Wat ikzelf veel belangrijker vind is dat de distortion/shaper wel per part is op de C.
Een C + medium reverb module lijkt me sowieso een betere optie dan een Ti met FX per part. Al is het natuurlijk wel gewoon handig om FX per part te hebben. Vooral delay. Wat ikzelf veel belangrijker vind is dat de distortion/shaper wel per part is op de C.
artists-choice
Ouwe rot
Heb nog eens gemailed en ik kreeg een mail terug met het antwoord
"We hebben nog geen release datum vastgelegt".
dus al met al vergeet die 2 weken maar.
"We hebben nog geen release datum vastgelegt".
dus al met al vergeet die 2 weken maar.
MikeJarod
ziet ze vliegen
- Lid sinds
- 3 december 2003
- Berichten
- 1.468
nen belg
Stamgast
Hierbij vergis je je wel. Het programmeren van effecten, synths, ... bestaat uit 90% uit wiskundige formules en 10% code. OK, bij een DSP programmeer je meestal (!!!) in assembler om het maximum eruit te halen wat erin zit, wanneer je een VST plugin gaat schrijven, dan doe je dit zelden in assembler maar meestal in C of C++. Maar die wiskundige formules zijn wel gelijk. 1+1=2 voor zowel een DSP als een GPU. Uiteraard is er meer ondersteuning voor het schrijven van VST plugins. Veel libraries waarin kant en klare effecten erin zitten, maar zulke libraries kun je ook vinden voor DSP's al zul je hiervoor wel moeten betalen vrees ik.
Enfin, dit is mijn gedacht hierover.
Acidfever
There's no "I" in denial.
- Lid sinds
- 12 Maart 2004
- Berichten
- 9.055
Helemaal mee eens. Er is echt totaal geen verschil in moeilijkheidsgraad tussen code schrijven voor DSP's of code schrijven voor VST instruments.
Het is een iets andere specialiteit maar meer ook niet.
Dan zou dus code schrijven voor een Nord Modular moeilijker zijn dan code schrijven voor bijvoorbeeld Native Instruments Reaktor. Beide hebben echter schokkende overeenkomsten en reaktor is zelfs nog een stukje complexer dan de Nords. Native Instruments heeft inderdaad een klein leger wiskundige specialisten om zeer complexe berekeningen, formules en algoritmes samen te stellen voor hun software.
Kant en klare DSP library's zullen denk ik vrij weinig gebruikt worden. Maar er zal wel veel tijd besteed worden aan eigen formules en algoritmes. Of het nu om native spul gaat (VST/VSTI/RTAS) of spul dat op DSP's draait.
dries
Stamgast
wat een onzin allemaal - VST levert een ontwikkelomgeving die "kant en klaar" is.
bij een DSP moet de programmeur alles zelf gaan opzetten.
ga terug aan jullie werk - kletsmajoren!
Acidfever
There's no "I" in denial.
- Lid sinds
- 12 Maart 2004
- Berichten
- 9.055
Ach wat een $%#verhaal zeg. Dus jij zegt dat het ontwikkelen op een VST SDK daarom maar even makkelijker is dan op een DSP platform?
Echt, ik weet niet waar je dit op wil baseren maar het is onzin!
Motorola (een DSP fabrikant) levert ook gewoon SDK's voor hun DSP's hoor. Geen probleem. (Ik zeg niet dat deze gebruikt worden).
Als je ergens iets gelezen hebt maar verder geen inhoudelijke kennis bezit (of je argumenten onderbouwt) zou ik het respecteren als je je mond houd in plaats van een loze opmerking plaatsen. De aanwezigheid van een SDK verandert echt niets aan de complexiteit van het ontwikkelen van een VST instrument of effect. Een SDK is per definitie niet "kant en klaar".
Toegegeven moet je bij een hardware platform in het begin iets meer rommelen omdat de SDK van VST gewoon redelijk goed is gedocumenteerd door steinberg. Maar als je daar langs bent is er echt niet zoveel verschil meer (behalve dat je bij DSP's vaak met irritantere talen moet werken).
Echt vreemd dat DSP programmeren als een soort heilige graal wordt gezien ten opzichte van andere software (want het is nu eenmaal beide software).
dries
Stamgast
fuse
Gepokt en gemazeld
- Lid sinds
- 7 juli 2001
- Berichten
- 18.831
DSP programmeren kan iedere jan doedel die een beetje logisch na kan denken.
De wiskunde die erachter zit zoals Fourrier en consorten bedacht hebben is een heel ander verhaal.
Dan zit je toch op HBO/Universitair nivo te praten.
Maar naast het DSP programmeren moeten de heren van Access ook software schrijven dat goed in multiprocessor omgeving moet werken. Stabiel moet zijn voor windows en OSX. En dat ze een jaar uitlopen is op zich geen schande.
Alleen zijn ze erg onhandig met het communiceren naar hun (toekomstige) klanten.
De wiskunde die erachter zit zoals Fourrier en consorten bedacht hebben is een heel ander verhaal.
Dan zit je toch op HBO/Universitair nivo te praten.
Maar naast het DSP programmeren moeten de heren van Access ook software schrijven dat goed in multiprocessor omgeving moet werken. Stabiel moet zijn voor windows en OSX. En dat ze een jaar uitlopen is op zich geen schande.
Alleen zijn ze erg onhandig met het communiceren naar hun (toekomstige) klanten.
RedTitan
wordt ooit nog eens Josti
Ik zie dat we hier in ieder geval genoeg mensen hebben zitten met kennis van VST en DSP om een opensource virus te maken? Waarom tegen elkaar in duwen mensen!
Waarom bouwen we zelf geen VST interface voor de Virus A/B/C. Als het allemaal zo makkelijk is! Kunnen we verkopen aan Access, en van het geld een leuke meeting organiseren oid.
Waarom bouwen we zelf geen VST interface voor de Virus A/B/C. Als het allemaal zo makkelijk is! Kunnen we verkopen aan Access, en van het geld een leuke meeting organiseren oid.
Acidfever
There's no "I" in denial.
- Lid sinds
- 12 Maart 2004
- Berichten
- 9.055
Het is niet zozeer dat ik heel veel verstand heb van het programmeren op zich, maar wel van de procedure erachter.
Ik ben namelijk van beroep softwaretester en heb al vele DSP/Embedded en native applicaties getest en door nauwe samenwerking met ontwikkelaars weet ik gewoon hoe zoiets in elkaar steekt.
DSP coding als basis is zoals Fuse al zei echt niet moeilijk. De wiskundige meuk achter audio software is wat het echt complex maakt.
De interface maken om de knoppen van een virus te bedienen zou met de VST SDK echt niet lastig zijn. De interface maken om er audio en midi in en uit te krijgen zal wel iets lastiger zijn.
RedTitan
wordt ooit nog eens Josti
Is er een audio programmeur in de zaal? We hebben een proffesioneel tester, en een projectcoordinator. We zoeken nu nog een VST programmeur, en wellicht iemand die op software niveau extra plugins kan schrijven. Wat ik nu voor ogen heb:
Een VST applicatie die het mogelijk maakt
- om geluiden te bewerken (aka soundquest/sounddiver) met library functie
- om audio van een ingang af te vangen
- en vervolgens vst effecten er op los kan laten.
Iemand nog meer wensen voor je A/b/c/classic?
Met een platform als de Chameleon is het maken van een synth eenvoudiger dan met de Cubase VST SDK.
In dat geval is het maken van een DSP synth dus eenvoudiger dan een VST synth. Waarom? Soundart levert een geweldige SDK met een volwaardige IDE, een goede toolchain, en alles werkt out of the box. De VST SDK is niet denderend (understatement) en je werkt niet op een gestandaardiseerd platform.
Wanneer je zo'n mooi platform niet hebt, moet je dat werk zelf doen. Nee, je kan niet zomaar een Motorola reference design pakken, daar een DAC op schroeven, en gaan met die banaan. De gehele toolchain van Motorola is totaal niet gestroomlijnd. Logisch, want hun DSPs worden toegepast op veel en veel meer gebieden dan enkel synths.
Wat wel helemaal waar is is dat een belangrijk deel van de ontwikkeling zit in de audio algoritmes an sich, en of je dat nou in C++ met embedded assembler of pure assembler programmeert maakt weinig uit. Het zijn de randvoorwaarden eromheen die er toe doen.
En de TI? Levering naar de winkels binnen twee weken, voorspel ik.
In dat geval is het maken van een DSP synth dus eenvoudiger dan een VST synth. Waarom? Soundart levert een geweldige SDK met een volwaardige IDE, een goede toolchain, en alles werkt out of the box. De VST SDK is niet denderend (understatement) en je werkt niet op een gestandaardiseerd platform.
Wanneer je zo'n mooi platform niet hebt, moet je dat werk zelf doen. Nee, je kan niet zomaar een Motorola reference design pakken, daar een DAC op schroeven, en gaan met die banaan. De gehele toolchain van Motorola is totaal niet gestroomlijnd. Logisch, want hun DSPs worden toegepast op veel en veel meer gebieden dan enkel synths.
Wat wel helemaal waar is is dat een belangrijk deel van de ontwikkeling zit in de audio algoritmes an sich, en of je dat nou in C++ met embedded assembler of pure assembler programmeert maakt weinig uit. Het zijn de randvoorwaarden eromheen die er toe doen.
En de TI? Levering naar de winkels binnen twee weken, voorspel ik.
