@PsevdoNimB, всмысле, в лайме же не пересемплено все с нуля, там как были старые консоли и эквы, так и остались, добавили экв С и консоль, откуда этот экв был семплен. Тот же алгоритм и у пинка. Он сам об этом на фейсе ми писал, про лайм, по крайней мере точно.
Можно линк на ту статью?
А, не, то в мануале читал.
1- LINE bank - MONO PREAMPS This group of emulations consists of all the new LINE preamps derived from the sampling of a vintage console from which we derived also the C model of equalizer. А карло писал, что С экв - это какой-то мега редкий, с мега редкой консоли вроде.
Если бы они семплили с нуля старые 2 консоли, почему тогда не сделали мульти преды для них. Уж 88RS явно круче, чем какая-то левая модель ( предположительно,
эта )
Я вставлю сюда весь текст.
I see that the point about updates is often not clear, I try to summarize some things that I had written a while ago. I would like to describe our process to you, a little so that you can get an idea of what to expect, a little to discuss why we do things in a certain way, and a little to discuss with you about the process, whether it can be improved in any way.
When we release a product from scratch or update there is a phase where the product is "under review". Usually all the main tickets that we receive in a timely manner, ranging from day one to the end of review or so, are somehow evaluated for fixes.
The problems are divided into a few categories:
- Replicable problems, and valid for the majority of users: we usually stop whatever we are doing to fix these problems. We usually talk about graphical problems, fixable errors such as interpolation errors, or obvious problems such as pressing a button and selecting the wrong sample. So we talk about malfunctions that have escaped the beta testing, and I see that in new products they are less and less.
- problems that are not replicable, and usually valid for a minority: depending on the number of tickets we receive we try to replicate the problem. We always try to replicate a problem, and the more tickets we receive, the greater the effort. In the case of very few users, sometimes we propose a refund: in fact, if the problem is difficult to identify, it may become impossible to find it in time, or uneconomic. Imagine selling a few thousand plugins and having a couple of users who can't run it on their machine, we sometimes prefer to refund the user, especially if we have no way to replicate the problem. If the problem arises for a larger number of users we can consider doing remote sessions and looking for a common point between the various installations. The goal is always to replicate the problem: currently, engines are very stable for a very large number of people (we're talking about hundreds of thousands of users for some free products), so if we find a limited number of non-replicable problems it could be a very difficult problem to identify, such as a conflict with a plugin from another developer, or a specific version of sequencer not used by many, or a detail of the operating system that is usually not configured in the same way for most users.
As soon as the product comes out of the review phase, it is frozen, and you usually address the remaining issues in a later update, such as the new version of the product. In this case, several things can happen:
- the product is rethought from scratch, and in this case we fix some design problems with all the new techniques, or improve the sound: for example we use new techniques to reduce residual noise, or ripple, or fix some obvious problems such as volume spikes and so on. Lime has been part of this category, for example we have processed all the samples of the past from scratch, also fixing some interpolation errors in a definitive way. We worked to reduce residual noise.
- The product is partially updated: in this case for example we add some modules, and try to fix some known bugs reported in the meantime. Pink for example belongs to this category: we have kept the previous features, we've brought to core15 preamplifiers (limiting ringing) and we've added a module. The product features remain unchanged.
Clarified this point, let's make some examples: some users have recently reported problems with Gold3. The problems were as follows
- recall problems
- spikes problems when activating some controls
I looked into it with support and found out that
- because of the recall problem, the tickets raised were extremely low. And I'm not talking about the first period, I'm talking about the whole period, from release to now. Basically, the most significant ticket came from a user who was a bit messed up with the symbolic links
- spikes problems were quite common to our products at the time the product was released, and they were part of what we could do at that time. However, some problems are sometimes solvable, in this specific case again we received a few tickets.
When and how to expect the changes? If we find a clear reason that causes the first problem we could release an update even in the short term. For the second problem it is a structural problem, which we usually address when we release a new update. In fact to get to an effective solution we often have to intervene heavily on the product and we have to plan a very accurate structural intervention, and it makes sense to do so by investing also in the addition of features.
In both cases it is crucial that we receive reports of problems as soon as possible, certainly before the product comes out of the review phase.
Все Favorites слетят