Jump to content

Sascha

Advanced User
  • Content Count

    1,422
  • Joined

Everything posted by Sascha

  1. Well, here's some background story, trying to clear things up a bit: Samplitude 11 (regular/former 'classic' version as well as 'professionell') contains already 'VariVerb Pro'. It's the same as the VST version we sell seperately. Maybe that already answers your question Samplitude Producer (US), Samplitude Music Studio & Music Maker come with 'VariVerb', without 'Pro'. The name implies a stripped-down version. However, I'd rather call it a predecessor, sort of a design-study for the 'Pro' version. This reverb was first introduced in a consumer product (Music Maker). Later on, it was chosen as the design framework for more internal studies, hopefully as a platform for a more advanced product. That became VV Pro. The small version includes mainly 'classic' algorithms, inspired by those known from old Lexicons and similar 80/90s devices (those 'in-a-cloud' reverbs, tons of impulse smearing). The 'Pro' variant has those as well (labelled as 'retro room/hall/plate' in its 'model' list), but all other models/algos were designed from scratch, especially the HQ models, which are designed for offering more complex reflexion patterns and more realistic signal scattering. Although the 'retro' algos are very similar in both products, they actually contain different parameter sets. Therefore, the two versions aren't really comparable. In hindsight, we should have perhaps chosen another name for the Samplitude version. But finding a name for a reverb can be even harder than building one
  2. Ohne jetzt ein B-Bashing vom Zaun zu brechen (bin langjähriger DDX-3216-Fan, via ADAT an Emu1212), denke ich, dass Du Dich für eine der beiden Geräte entscheiden solltest. Am stationären PC würde ich immer PCI/PCIe einer USB-Lösung vorziehen, allein schon aus Gründen der Systemlast und dem ganzen Hickhack mit nicht erkannten USB-Devices an ungeraden Tagen und bestimmten Mondphasen... Unabhängig davon, ob Du das Monitoring mit dem UGC solo hinbekommst (was ja laut B. so sein sollte): Viele Leute klagen über 'rauschende' Modeling-Amps am Rechner, über flachen, statischen Sound. Es klingt paradox, aber der einfachste Tube Amp in Handverdrahtung verstärkt effizienter als viele hochintegrierte Audiosysteme (zumindest für diese Anwendung). Du brauchst für Zerrsounds soviele Bits wie möglich (digitale, nicht das Bier ). Ich hatte das mal im Vandal-Manual geschrieben; wenn du 'n High-Gain-Amp hast, macht der ohne mit der Wimper zu zucken mal eben 60dB Gain. Bei einem 16bit-Device wie dem Guitarlink hast Du nach oben sehr wenig 'Luft', d.h. langes Sustain bei viel Gain kippt mitunter ins 'Quantisierungsrauschen' über. Darunter kranken viele 'kleine' Lösungen (UGC, StealthPlug etc.), ist also kein Problem des B.-Gerätes per se. Für höherwertigeres Gitarrenrecording würde ich halt eher an einer richtigen Karte einen kleinen Preamp wie den Art Tube MP (~39€) oder eine andere DI betreiben, oder notfalls einen (rauscharmen) Bodentreter (auf Bypass, aber der darf nicht 'true-Bypass' sein). Das M-Audio solltest Du zu Deinem Haupt-Device erklären. Müsstest nur sicherstellen, dass Du irgendwo einen Hochimpedanz-Eingang für die Harfe hast (Hi-Z). Wenn das M-Audio nur Line & Mic hat, müsstest Du was vorschalten. Sehr beliebt (auch bei uns hier) ist der kleine Art, weil er netterweise ein leicht 'aufgeheiztes' Signal mit genug Headroom liefert, indem er die Spitzen leicht abfedert. Man kann mit so einem Signal gut weiterarbeiten; manchmal merkt man das erst im Zusammenspiel oder im Mix. Nimm zum Geräte-/Monitoring-Test mal irgendeinen ausgemusterten Boss/Ibanez/sonstwie-Treter und schalte den mal vor das M-Audio, betreibe das Ding unter ASIO, Hybrid-Engine aktiviert, Latenz kleiner 256 Samples (so niedrig wie möglich). Und drauf achten, ob Samplitude (unten rechts) ASIO-Aussetzer anzeigt (sollte nicht sein).
  3. Hi, probably the smoothest graphics update scheme of the bundled/VST plugins is within Vandal, mainly because it uses an updated drawing library with a better architecture. The older plugins still suffer from 2 things: 1) The meters, knobs and other animations only get updated when the GUI thread is idling. This, of course, depends highly on the current project, and it might get worse with high track count and lots of stuff happening upon playback. 2) The mouse handling is somewhat 'modal'; means tracking the mouse cursor, when you press either button, slows down the rest of the GUI, or freezes it completely for a moment. In my most recent UI code lib, these 2 design flaws are gone. Likewise, all older plugins which are subject to updates will get improved one after the other within the next months. However, I can't say much on the Sam standard (dialog-based) plugins. Perhaps Volker or Toni (E.T.) are the ones to address that one to.
  4. Hi Bob, 1) Currently, we don't have a ready-made simple architecture for wrapping the VST plugin in order to form a stand-alone app. For the moment, I'd recommend the free savihost (hermannseib.com) if you just need an audio engine and don't need a full-featured sequencer for the plugin. 2) OK, I'll add that to the list. Good point. 3) Been working a lot on this lately. Completely redesigned the LCD behind the 'wrench' and added a 'midi patch list'. Changed the whole behaviour of how to switch presets & scenes, hopefully more comfortable. But there's still a lot to do. I'll post some info later this week in the blog, as soon as I find some time. 4) No idea here. I've always been happy with 'traditional' sequencers, even on stage.
  5. Die VST-Version ist hat einige Schwachstellen in der Speicherarchitektur, die wir in der Sam-Version bereits bereinigt hatten. Ich vermute, dass das bei 64-bit-Hosts nur stärker zum tragen kommt. Aber auch bei der Sam-Version sehe ich noch Verbesserungspotenzial, vor allem was die dynamische Speicheralokierung betrifft. VariVerb benutzt im Vergleich zu einfacheren Reverbs ziemlich viele Delaylines (bis zu 64), da kommen pro Instanz je nach Sampleraten schnell mal einige hundert MB zusammen. Das kann man unter der Haube besser verwalten. Stichwort 'high track count'... Wir werden das ganze im Zuge der 64-bit-Umstellung und anderer Modernisierungen in den nächsten Wochen verarzten. Nach Momentanen Stand sollte es im Nov./Dez. soweit sein.
  6. VV ist von Anfang 2007, zumindest die VST-Variante. Da war noch nicht viel mit 64bit-OS. Wir planen aber gerade eine komplette Runderneuerung und stellen Entwicklungsumgebung, Systembibliotheken und die Plugin-Codebasis darauf um. Konkretes dazu kann ich aber erst dann sagen, wenn die ersten Tests erfolgt sind. Aber wir halten uns ran
  7. Hi Peter, danke sehr für diese wertvollen Infos! Ich bin aktuell an einigen Midi-Umbauten dran. Dazu gehört die geplante Patch List und ein neues Handling für Preset & Scene up/down. Das eigentliche 'Problem' beim Vandal ist ja, dass auf der Platte theoretisch unendlich viele 'Presets' sein können. Dazu noch mit beliebiger Verzeichnistiefe. Bei Midi hingegen ist man auf 128 'Programs' beschränkt. Deswegen wird es im Vandal ja die 'patch list' zum mapping von Mii-Programm -> Preset auf der Platte geben. Genauer gesagt kann es unendliche solcher patch lists geben, denn ein solches Mapping wird als 'patch list preset' gespeichert. [Wer z.B. Cover-Musiker ist und je nach Abend andere Setlists im Wechsel spielt, dem wird geholfen...] Bliebe noch die Sache mit scene select und up/down. Scene select: hier denke ich, dass eine source-Auswahl sinnvoll wäre - Note number 0..127, konkrete Auswahl des ersten Notenwerts (tatsächlicher Wert (byte 2) egal) - CC number 0..127, konkrete Auswahl des ersten CC events (auch hier Wert egal) - CC number, CC value = Scene (-> byte1 = xxx, byte 2 = 0..3) Up/Down: Momentan würde ja ein inc/dec ein presetfile vor oder zurück auf der Platte wandern. Das halte ich durchaus für eine 'Krücke'. Ich denke, logisch wäre eine Steuerung in der Midi-Domäne, d.h. 0 - 127. Somit würde nach dem neuen Handling der Controller bei program change 1:1 auf die Patch List zugreifen. Grundsätzlich besser, oder nicht? Bislang merkt sich Vandal das letzte program change und bildet das delta. Abhängig davon wird hoch oder runter geschaltet (so viel wie das delta sagt). Dass Du beim GR controller auch nicht sofort drauf gekommen bist, zeigt, dass meine Implementierung ganz großes Damentennis war... also ganz schnell weg damit... Für up/down (patch list, nicht mehr preset) würde ich daher eher folgendes für eine Listenauswahl einplanen: - up-> - Note number 0..127, konkrete Auswahl des ersten Notenwerts (tatsächlicher Wert (byte 2) egal) - CC number 0..127, konkrete Auswahl des ersten CC events (auch hier Wert egal) - down- > dito Damit man im Eifer des Gefechts nicht mit diesem ganzen Preset / Patch-Kram durcheinanderkommt, würde ich das Haupt-Display soweit ändern, dass man dort von [FILE]- (momentaner Stand) auf [PATCH]-Ansicht umschalten kann. Also ungefähr: File-Modus geklickt (default-Zustand, wie momentan): | [>FILE<] [R] Mein tolles Preset.vpr [ < ] [ > ] [S] [?] | [PATCH] | | - remote 1 - remote 2- ... | CC 007 CC 001 ... In diesem Fall arbeitet man direkt auf der Preset-Sammlung auf der Platte. up/down würde dann nur über das GUI funktionieren, nicht über Midi. Patch-Modus geklickt (neu): | [FILE] [R] Mein tolles Preset.vpr [ < ] [ > ] [S] [?] | [>PATCH<] | | - remote 1 - remote 2- ... | CC 007 CC 001 ... Hier wird auf der Patch-Liste gearbeitet. D.h. in der Drop-Down-Liste befinden sich immer 128 Einträge, entweder vergeben oder nicht. Up/down funktionieren sowohl lokal als auch über Midi. [im übrigen wird diese Patch List auch nach VST exportiert, d.h. genau die ist im hostseitigen Plugin-Dialog und z.B. im Track-Editor von Samplitude verfügbar.] Das 'patch list preset' (s.o.) würde platztechnisch aber nicht mehr draufpassen, das müsste man in der 'config-Ansicht' (Schraubenschlüssel...) machen, da wo die Liste gefüllt wird. Ist aber wahrscheinlich kein Beinbruch. Wenn ich soweit bin, werd ich das mal alles im blog posten, mit Grafiken. Dann sollte das alles klarer werden. Vielleicht fällt dann noch das eine oder andere auf, das ich evtl. übersehen hab. Midi Control ist ja alles andere als trivial... Prima, her damit (presets@vandalamps.com)! Gruß, Sascha
  8. Hehe, good point. I got two additional stomps done already for the next round, and a third one is in on the desk. I also have to expand the post-fx units in a calm minute. But a synth pedal is also on my mind, for a long time. I hear you.
  9. Hi Bob, thanks for posting the link here. Of course we are curious on what projects our products are used. Especially with Vandal. Some of your songs from the list don't seem to be correctly linked (404 error), but the ones I could hear are great You said 're-amped'. What gear were you using on-stage?
  10. Hi Bob, I'm a bit puzzled about the message box you posted. Never seen this. It's Samplitude, though, not Vandal. But that's a symptom, most probably not the cause. I can imagine something screwed-up inside Vandal having triggered that. About issue 1: have you updated to Sam 11.1 yet? We got no crash reports upon load/save with the latest version, at least none that I know of. If it really happens with Vandal v1.103 (latest Sam variant), please let us know what you did exactly, so that we can perhaps reproduce it here. Or are you using v1.104 already (VST version)? Issue 2, Midi: I recently could reproduce problems when switching presets or scenes via Midi on-the-fly, while doing that directly on the interface seems solid. Still have to figure out here where the culprit hides. That's got high priority. Midi handling will get enhanced & expanded anyway in future versions. About preset numbering: I plan to offer a flexible midi patch list page, where you could freely map any existing preset to any of the 128 midi programs. Currently, Vandal's startup preset can be set in the global settings (although totally unrelated to midi). Upon program change, it currently just goes forward/backward within a given folder (while being unable change to another directory, as the underlying mechanism wasn't designed for remote traverse). That's in no way flexible, therefore the planned seperate patch list. This also deals with the 'problem' of gathering hundreds of presets, with arbitrary folder complexity. I also considered providing exchangeable patch lists. That might be handy upon excessive gigging, where you might change set lists often. > It has gone back to the default setting on every one. I recall a problem with the plugin accidentally loading in the default preset *after* having received and applied the stored data from the host, but this was addressed in 1.103. Please check again if that's your version ('about' page, click on the wrench symbol next to the tuner). > As stated earlier, I fully intend to stop using my Fractal FX Ultra in favour of Vandal ASAP. Haven't had the chance to check Fractal yet. People seem to be full of praise for it. OK, compliments taken, I'll do my best for your conversion
  11. Hang on a second. No need, to reinstall and 'compare' the files on your side. At least not against each other, that's of no use. I just need the raw checksums of each one. About the 'virus issue'. Often, scanners produce false positives. Plugins may trigger their alarm system because they often operate on a very low level, 'close to the machine', if you want. And many are unpacking certain parts at runtime, which a scanner could interpret as 'self-modification', thereby sorting it out as a virus.
  12. OK, thanks for reporting. We'll look into it at the next opprtunity. In the meantime, I hope you have some fun with the PC version
  13. Sorry for that. We're currently confronted with the fact that some hosts on the mac seem to have problems with dynamic UI resizing. Seems to be quite common, but we weren't aware of that when we ported stuff over from Windows... *sigh* Vandal's window can hide the different components views, according to taste. For that, there's a 'global option' on the interface. Of course you can't see that actually... but there's a way: - please open /Library/Application Support/MAGIX/Vandal/Vandal.ini - locate <key>gui_resize_mode</key> - directly below that, change <string>1</string> into <string>2</string> and save the file Let me know if that does anything about the problem. Thanks.
  14. Argh, sorry. Haven't seen that before. I'll be on vacation the next two weeks, but I'll look into that as soon as I get back. About the other problem, can you please do the following: - please download and unzip this tool: http://www.winmd5.com/download/winmd5free.zip (it's very small and doesn't need installation) - go to the '_bin' subfolder of your Vandal installation, and drag&drop these files onto the winmd5 window: IJL10.DLL MagixOFA_u.dll MagixOFA-en.dll MFL_u.dll Protein.dll PlayRIpl.dll PlayRIplPX.dll -let me know about the strings the tool spits out Thanks.
  15. Just a quick question (curious here): in which host does this happen? I can't reproduce it here, neither in Samplitude, nor in Reaper.
  16. Sorry, there is no such way (neither technical nor in terms of licensing). Due to current roeadmaps and priorities, development on Vandal is constantly taking place. But we don't synchronize that with Samplitude update releases (which would just slow down things in other corners). So, although one version may be always ahead from the other, this is not intended. But we try to keep release time spans and feature discrepancy as close as possible.
  17. We don't have a Vandal-specific forum yet, although we considered that. Setting one up is easy on the technical side, but someone needs to take care 24/7. As there's always so much to do for everybody (and we often attend this place during our spare time), this is no easy taks Anyway, thanks for bringing that up here. We sense a growing interest in the product lately, and there's surely something we should do.
  18. Du kannst momentan z.B. program 1 - 4 senden, oder auch 34, 35, 36, 37, Hauptsache 4 diskrete Werte. Wenn ein neues reinkommt, nimmt Vandal das delta (neu = program - altes_program), wenn > 0 = Szene +1, sonst -1. Ist natürlich blöd, wenn die Startszene ungleich 0 ist. Gerade heute haben wir die VST/AU-Version 1.104 online gestellt. In der nächsten (noch ohne Termin) wird eine Midi-Patchliste und ein neues Szenenhandling drin sein. Da muss ich mir noch 'ne Rübe machen...
  19. GUI = Graphical User Interface. Halt das Fenster mit den lustigen Knöppen, wo manchmal was flackert oder auch mal ein Aschenbecher oder 'ne Kaffetasse im Weg rumstehen
  20. Hm, kann's hier gerade auch reproduzieren. Allerdings nur, wenn das GUI offen ist. Kannst Du das bestätigen?
  21. OK, ich werd's bei nächster Gelegenheit untersuchen. Danke für die Einzelheiten.
  22. Sorry, aber mir ist gar kein Crash bekannt. Ich dachte, ich hätte alles dort erwischt... hier jedenfalls alles unauffällig. Hast Du 'ne Möglichkeit, das Szenario mit 'ner Screencam aufzunehmen?
  23. Ist fertig, gerade noch in der Test-/Freigabe-Pipeline. Sollte in den nächsten tagen online sein. TBA
  24. Scenes are controlled via program change. That is far from perfect at the moment, and it will change with future versions. Currently, when Vandal receives a program change event, it compares that to the last one. If it's greater, it advanced one scene (or preset). If it's smaller, it goes back one scene (preset). What to do upon program change can be defined it the 'global' tab view. This often far from perfect, I know. That's why it will change. One of the next versions will introduce a 'patch list' scheme, where the user can map actual presets to any midi/vst program. So that the presets are already out of the way of scene controls. Controlling either thing will be more flexible, selectable out of a list of dedicated events, program, cc or note, I think. Which Vandal version are you refering to? Scenes can't be saved seperately. A scene is an 'alternative setting' of the current preset. But when you click 'copy', the current one is held in memory until you unload the instance. So it also survives loading in a new preset. This way, you can create presets more easily, for instance by pasting memory scenes to a new/temporary preset that you change later on.
  25. As Revolta is not available as a regular VST plugin, the user base is perhaps relatively small. The instrument was included in MusicMaker & MusicStudio for quite a while, but I guess somebody just starting making music might perhaps be a bit overwhelmed and prefer something simpler. Samplitude is probably the better environment. I've come across a (German) blog where the author created two soundsets, which are actually pretty good: http://www.selber-musik-machen.de/download...volta-2-sounds/ The factory set was done by Nico Herz from bigtone.de. He's one of the best sound designers I know, his references include refx, Cakewalk, Digidesign, linplug, Camel Audio etc. Revolta was kind of build around the actual sound design (was a bit quick&dirty and hit&miss, Nico always blames me when we meet...). A very evolutionary process, he came up with a couple of design flaws, said this-or-that was a no-go, I trashed parts of the engine and rebuilt things from scratch etc. For instance, the mod matrix wasn't planned initially, Nico insisted on it, I had to squeeze it in, and it pushed the whole product really onward, in its mightyness. Although I know its architecture in & out, I'm sometimes still asking myself how a certain sound was created If you have cool sounds, I'd be curious to hear
×
×
  • Create New...