Jump to content


Advanced User
  • Content Count

  • Joined

Everything posted by Sascha

  1. 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. 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. 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. I mean the same. VV is capable of that.
  7. A true stereo version would be so cool! Hm... most Models in VV are already true-stereo (rooms, halls and the HQ algos).
  8. 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. 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. 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. 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. No, these plugin don't know anything about wibu. And, honestly, I can't imagine we'd change that in the near future.
  14. 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. 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. 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. 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. 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. 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. 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. 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. 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
  23. 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.
  24. 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.
  25. We got 'vintage' fx in MusicStudio (these stomp-box UIs) and a 'vintage' suite in Sam/Sequoia(the ones with the 'pilot series' look). Although the name is the same, these plugins can't be interchanged. You can consider the MusicStudio fx being sort of 'prototypes', and the 'pro' versions as more evolved/mature. Maybe it's possible to add the MusicStudio fx to Sam/Seq, but I'm not sure if no side effects occur under the hood (internal IDs and such). We'd have to inspect that here. I personally see a product type / name mismatch which I wouldn't want to mess with and rather keep the house clean instead. Perhaps this calls for some 'migration' installer or the like. But that's basically product-management land, for sure. On the MusicStudio tape sim: it's exactly the same as the one from am-track until Sam8.3. The latter got huge DSP code updates with v9 which also resulted in sonic improvements.
  • Create New...