Jump to content


Advanced User
  • Content Count

  • Joined

  • Last visited

Everything posted by Sascha

  1. Sascha

    Drums on Demand

    Aren't DOD usual WAV files? Then, you could place it anywhere and just drag them into your VIP (for instance, using the manager from with Samplitude). BTW, I just found ithis on the DOD site: http://www.drumsondemand.com/content/sampl...hese-samplitude That points directly to one of the great videos by our forum regular Kraznet.
  2. Yes, we'll make it public. It's such a highly demanded thing, I guess I'll have to walk tarred & feathered in the street, wearing nothing but a megaphone... (my office is 30 meters from Berlin's 'Checkpoint Charlie')
  3. Sorry, I discovered this thread so late... (we devs do this often in our spare time, as this place is not our official support. And I was on vacation lately.) We are aware of the VV crash in Reaper (which is just very picky, btw). That bug was addressed a while ago, but due to internal resources, only made its way into the Samplitude version yet. I'm currently setting up a detailed roadmap for plugin updates (which are *many* meanwhile, and all updates include a lot of new added features anyway). I know bugs such as this have quite an impact, so consider that of pretty high priority. Will do my best here.
  4. Sascha

    VariVerb as 5.0

    Hm... it took me almost 1.5 years for the various VV algos. And that's 2 channels. Now you can do some calculus Seriously, I'm not saying anything. As usual, we like to listen and gather feedback here. But any statement on future plans isn't up to us devs, no matter if 'yes' or 'no'.
  5. Sascha

    VariVerb as 5.0

    Yeah, please try with a stereo input, perhaps test with pre-fx panning or so. You should be able to notice that extreme panning doesn't result in extreme reverb on either side, of course. That would be the case with dual-mono reverbs. VV's room/hall algos work with a matrix of delays that span a mesh over the 'virtual room' and take the source channel seperation and positioning into account. That should result in natural localisation. Let me know if that works for you.
  6. Sascha

    VariVerb as 5.0

    I mean the same. VV is capable of that.
  7. Sascha

    VariVerb as 5.0

    A true stereo version would be so cool! Hm... most Models in VV are already true-stereo (rooms, halls and the HQ algos).
  8. Sascha


    Hi Andrea, things you should consider: - the midi ctrl should be done from a seperate track (set to MIDI there) - enable monitoring on both tracks - enable hybrid engine The rest inside vandal is fine, from what I've seen from your video. The global page has no meaning here (will be fixed anyway soon). There's also a bug with the amount slider, but that basically doesn't affect the general workflow. External messages should come through nonetheless. There were reports were saving the whole midi setup doesn't work properly. This is about to be fixed soon as well. Regards, Sascha
  9. Sascha

    FR: mix options & mutes

    Thanks for these constuctive tips. Will be considered. Whenever I get my hands back on these plugs, I'll give the UI part a revision anyway. Don't know quite whan that is, currently. Will do my best. Sascha
  10. Sascha

    Preset Bibliothek

    Du hast recht... die Presets sind wirklich gut, vor allem die Arpeggiosachen. Hut ab.
  11. Memory leaks & memory consumption are under inspection here. I've moved quite a bunch of code around last time, but I need to run a couple of tests here first... I guess it should be okay if you copy the xxx_unlock.ini file of one registered plugin into the folder of the other. Haven't tested that, though. Does that work?
  12. Sascha

    Controlling Variverb

    VariVerb can be automated via standard Midi CC messages, as it says on the UI (and in the manual). At least is does here using 'ordinary' Midi equipment. I don't have access to a Nocturn here, so I can only ask you to try that again yourself and refer to the unit's CC mode. But: I do recall some problems with Novation's Automap a while back but I currently don't have access to those documents. Should your problem persist, let us know and I'll dig that out asap. Quick check: Are you using the regular/unlocked VST? AFAIR, the demo of VV wasn't initialised properly by Automap as one of the restrictions is '0 parameters to the VST interface', therefore no automation and no saving with a host project. Automap, at that time, insisted on VST automation data. Is it perhaps that?
  13. Sascha

    Plugin Licences

    No, these plugin don't know anything about wibu. And, honestly, I can't imagine we'd change that in the near future.
  14. Sascha

    Plugin Licences

    The unlocking step would be necessary when you make bigger adjustments on your hardware, such as changing your hard drive. A reformat shouldn't be the cause. I suspect you lost/deleted the xxx_authorisation.ini files. Right? Then, you'd have to re-do the unlock process. On the Wibu thing: we didn't want to go dongle-based here. Definetly. The products were aimed at non-Samplitude users, so it's likely a client doesn't own a CM key. Adding one always increases costs and hassle on either side.
  15. Sascha

    Robota Pro Loudness

    You're trying that in a demo version? It's been a while, but as far as I recall, I've disabled the saving mechanism in the demo.
  16. Sascha

    Robota Pro Loudness

    Don't judge too early on that. The grid is there for a convenient workflow, of course. But it's not only the grid for triggering sounds; you can use it to automate every internal parameter. It's the right features right where you need them which might count here. Not every user wants to fiddle with multiple windows.
  17. Sascha

    Robota Pro Loudness

    Development on Robota is more or less abandoned. But we got BeatBox2 as sort of successor coming up with V11. This thing was already introduced with MusicMaker /MusicStudio 15. It follows a relatively easy grid/step-sequencer apprach (more visual, less hardware-like), while offering a more versatile sound engine. It's 5 years between them, which I think is clearly audible Here's a video where I was giving a BB2 intro to journalists within a MusicMaker15 presentation here in our Berlin office last year. It's lengthy, but anyway...: http://www.feebs.nl/video/1032b5f55ef0d
  18. Sascha

    Robota Pro Loudness

    Well, that's mainly because the engine doesn't just playback polished and max-boosted samples. It's actually a modular synth, a VA, if you want. There is no fixed operating level on the inside, it can be anything. You can do extreme stuff if you twist it enough, including massive overdrive and filter resonance / squeals. It would be counter-productive and quite dangerous if we'd allow for a 0dbFS level right from the start. After all, we give you 32bits floating point. You just don't lose any quality by boosting the level afterwards. Headroom is your friend
  19. Sascha

    Is Feedback Routing Possible?

    I can exactly relate to what you're saying. I did some stuff back in the 90s where I did mixdowns, using an A&H Saber desk, and routed all kinds of stuff back & forth through it. It becomes fun when you build up delay clusters (for me at that time: Ensoniq DP/4) and send that to various auxes, through stomps, guitar stuff, and feed it back upon itself. (I've lately rediscovered old DATs with 30mins of drones/athmos, using only an LXP-1, and old MidiVerb, the desk and internal feedback. Really weird.) Frankly, I can't think of any gear that does that as good only in the digital realm. But I would try out this one: - put the delay (or whatever) on a bus (aux or submix) and send the signal to a spare output on your audio device - do some external processing, whatever you like that beefs things up - route the audio back into the sequencer Sam/Sequoia have a dedicated 'external hardware' worflow for these kinds of things. Latency is automatically adjusted (as long as the driver reports correct times). It doesn't interest the software what and how you patch things up externally, so there's plenty of freedom. You could also apply that multiple times, as much as you've got physical ins & outs. Of course this workflow is limited to already recorded audio, it won't work with live inputs (you'd have the in + out latency, certainly)
  20. Sascha

    Is Feedback Routing Possible?

    Yes, consider my above post as mostly humourous. Maybe I failed miserably. Of course I do 'recognize' that. Back in my analog days (being an FOH guy) I was doing just the same on various occasions. I know it can be a creative way, no doubt. Thing is, with analog, you have the internal voltage supply and the OP amps limiting the amount of signal level, thereby feedback. In the digital world, the only limit is the 80bit floating point range (more than 3000dB theoretically). Strange things can happen; denormals, overflow, underflow, with the 'NaN' state being the worst. If I'm not mistaken, we already have an internal limit here. Still, this isn't comparable to analog, of course. But I don't think level excursions are the main issue here. Apart from the fact that it is up to others here to decide that (I'm not involved into the core development), we're currently working on the entire routing scheme. Before V11, we got a left-to-right arrangement of tracks and busses, that we now extent to both sides, as far as our internal schemes allow. But afaik, there's still no feedback structure possible. I guess one reason is our hybrid engine, which, in contrast to most other DAWs, allows for a mixed operation of low- and high-latency track/bus arrangement. Another one may be threading. Perhaps Volker as the lead dev can clarify here further.
  21. Sascha

    Is Feedback Routing Possible?

    For the sake of our customer's hearing, we do not allow feeback routing. If Reaper does... well, I suppose it's in the app's name
  22. Hi everybody, as we've currently updated the Samplitude website and fed it with info on the 'unbundled' VST plugins, I'd like to take the chance and welcome all guests, users and whoever stops on by, to this new section of our beloved forum The current week has been the one where we've started shipping the first VST effects boxes to stores and distributors. We haven't performed much of a marketing blahblah and just compiled a few pages for the main Samplitude web site. Most of the stuff was directly taken from the manuals, so that anyone curious about the stuff is able to get a detailed overview on what it's all about without having to download & install the Samplitude demo (which I'd always recommend, anyways....). But that doesn't suffice, I know. As of today, we do still owe you demo versions of the plugins. There's not much sense in reading a bunch of pages without getting your hands on the stuff. That'll come next week, as soon as we've finished & tested the install package. Okay, this forum shall be the melting pot for everything concerning these plugins, their bugs (there's never any SW without...), your proposals & ideas, critique and whatever concerning future versions. I'll also try to give some additional info, background stories, hidden secrets that aren't in the manuals etc. Of course, as time allows. This forum is also intended to serve as a place where users should exchange their ideas, especially when it comes to questions like 'gimme some tips about the right compression settings for xxxx'... while we all know that there's never the 'right' setting, we do also know that switching some presets can be of great value at times. So, please: whenever you encounter a setting on one of these plugins that you'd consider helpful for others, too, don't hesitate to post them. I mean it. We'll see how we can arrange that best as things evolve. My initial assumption is that this could be first solved by attaching an fxp/fxb preset file to a post such as this. Maybe we have to gather stuff and create a sticky topic. We'll see. Surely, there's more to 'community' than changing presets, but you get the point Cheers, Sascha
  23. Sascha

    Welcome The Plugins Forum!

    Hey Greg, the code branch for the seperate VST plugins (still at v1.0) does indeed cause some trouble in some hosts (especially Reaper, where I've tried in 2.x myself). It probably depends on various circumstances if you run into that or not. Their Sam/Sequoia-bundled counterparts were fixed a while back and actually don't contain those showstopper bugs. A word on bug fixes: I've been quite optimistic a couple of times when it came to get that fixed. But as fate thought otherwise and I nearly got tarred & feathered lately because of not having provided something, I'm way more cautious now. Meanwhile, the whole internal code branch evolved and I simply don't want to just revert back to the old Sam/Seq state, just to build a maintainance fix. I've got plans where all those plugins (including our bundled ones) could profit from a couple of stuff from latest development (such as the flexible and future-proof XML-based preset file architecture like in BeatBox2, Vandal and eFX). But first, the work on Vandal and the essentialFX must be completed. I'll make a solid road map with the rest of the team and to get projects synchronised afterwards. Cheers, Sascha
  24. Wir haben das nicht vorgesehen, dass die internen Plugins aus der 10er Pro unter SE laufen. Evtl. gäbe es Abhilfe, wenn wir eine reguläre VST-Version von am-munition rausgäben. Betonung auf dem Konjunktiv. Ob und wann, dazu kann bzw. darf ich aber derzeit nichts sagen.
  25. Sascha

    Interested In Moving From Sonar

    Please don't mix up 64bit for *memory access* with n bits for *signal processing*. Apparently clever marketing words out there are leading to quite some confusion... so here we go: In most hosts (Sam/Sequoia included) audio data is processed using the <float> data type for streaming/processing audio, which means 32bits resolution. Floating here means, you get the precision where you need it within the available range, similar to a pocket calculator where the comma moves accordingly. Float can be considered 'common ground' when it comes to communication with an audio software, such as internal DSP data streams for buffers. Many DSP algorithms are fine with 32bits resolution. A few might need 64bits (by using the data type <double>), such as recursive structures like delays or IIR filters; otherwise rounding error accumulate pretty fast and so quantization noise increases. 80 bits resolution refers to the internal number representation of the FPU (e.g. IEEE standard), which means float & double both get expanded to the 80bits range. However, when calculations are done, numbers are stored back to the internal registers as either float or double, hence they get truncated. Surely a developer can work with 64bits all the time, but that means you cut the internal register storage in half and double the entire data stream. FPU-internal registers are fast, but any read & write access from outside and back takes valuable processing time. So one always has to outweigh things. Even when an algorithm calculates in 64bits precision, it is often more than OK to convert it to 32bits afterwards, as soon as any recursion is done. For instance, this is the case for a plugin when it hands back its buffer back to the host. 64bits as uses in the latest claims by other manufacturers mainly affects the memory managements, which is a different story. 64bits here means you get rid of the old 2GB limit, which is important for large projects and especially sampler usage. Perhaps Volker can add more info here what we've done within the program to cope with that. He knows best.