CV delay when using CV in Add
Ah, but using external adding is in order to avoid using the cv input on Elo. You just add e.g. the cv out of a track with another track or whatever cv you want to add it to.
Oh ok - I have to think about that solution. Can't grap it yet mentally 🤔 - needs some time.
It is amazing that I also encountered this phenomenon. But until now I didn't hack in a topic on it here in the forum, because I already had some othe issues to report.
However, I am also not really happy with ELOs behavior in this matter, as it hinders me to fulfill the idea of using the device in the way I thought it would be able to use.
Ok, sometimes it is annoying, but I can live with this because 'what else should I do'?
But for sure it would be great to be able to use ELO as a stand alone solution to do the transpose job Lars mentioned instead of having to buy another expensive module to finish the job.
So let me ask @wintermodular: Do you intend to let users have a look at the source code to help improve it?
As I understand until now it is a closed system, right?
at some point I will relase the code, but need to tidy it a little bit before.
The idea is to do it after the next firmware release
here I am again reporting the same issue we have been talking about long time before already.
But this time it goes a bit further, literally.
While some months went by, I spent both, time and money, to epand my hobby.
I build a beautiful 12HE104TE case, bought some MI Modules, and also got a EME. (Which also shows funny behavior, sometimes. But that's another story.)
All in all I was happy.
"Was" because now the issues me and others I have been talking about here are kicking in again.
And they come even harder as more and more I understand how modules work, how modular works, and as I talk to other people and their issues with certain technologies.
However, here I want to talk about that "Delay when using CV in Add" issue.
I think this should be get fixed. Soon.
As for now in my case I run this:
Track A is my Main Track that should transpose all other tracks exept B, C, D as they just fire Triggers for some Drum stuff.
On Track E and F I hacked in exact the same patterns, and I expect Track A to shift them up and down some notes.
So it happens.
BUT, as to speak with Lars words in the first messages of this topic,
instead of plaing "FFFF, GGGG, FFFF, GGGG" ELO gives me a heart attack playing
"FFFFFFFF, FFFG, GGGF, FFFG".
This, in my opinion, is inacceptable.
I don't want to sound mean, but I spent a huge amount of money on this gear, and time goes by while issues stay unfixed.
Actually I am a bit angry right now, even as I saw there is a new device on the run, while a 18 months old "matter of of some coding" stays untouched.
Please, Eloy, make things happen. Fix that issue.
Or, If you don't have the time, find another way to get that fixed.
Thank you very much!
Because you were talking about this, I pin you here:
If you guys solved the issue without buying another expensive module, I kindly want to ask for your advice. Thank you in advance!
If you understood the thread, it's not a bug : it can't read a value and write it at the same time, that's all and I think it's quite understandable.
So you request a new feature. There's no evidence it could be and will be done...
I faced the same problem, and finally bought the LPZW WK1 in Aroom config : http://leipzigwest.org/?page_id=39
A three channel transpose module with one common transpose CV input
Thank you for trying to help.
Maybe I just let too much frustration into my last message. I didn't want to hurt anybody.
As I understand it is like this:
There is a programmed sequence that need to get changed from another sequence.
That means that there are two rows of numbers that need to get added.
From my perspective there is no reason to read either one of those numbers as they are already written in the sequence to play.
I am not sure if I made myself clear, but thinking of it for me it is very clear and also very logic.
There are a number of steps in Track A, which is the "Master Track to transpose other Tracks -> write into cache
Track B should play melody and get transposed by Track A -> write into cache
ELO should do a mathematical addition of both caches step by step -> play from cache
3 3 3 3 6 6 6 6 2 2 2 2 - Track A, Transpose Track
1 4 2 6 3 2 1 3 5 7 4 6 - Track B, Melody Track
4 7 5 9 9 8 7 0 7 9 6 8 - Resulting CVs to give out to VCO
Now ELO should be able to play from that cache
As the Transpose Track is something that would not get changed during the performance, it must not get calculated or read.
The Melody numbers have to be read, but not every time the next step is to be played.
It is Music, which follows rules, that most of the time don't change just by accident. Exeptionally for Free Jazz, I guess.
In my eyes, as I understand what I know from Music, and what I know from programming (not that much), those numbers won't change that often that they have to be read each step by step, no?
Maybe I am wrong.
But thinking of what I have in mind again and again makes it more and more logic.
This issue has never only been a 'matter of some coding' I understand it as a concept problem, not a question of code it or not. There are ways to avoid the concept problem but those could introduce new problems.
Let's try to understand it, the internal sequence that the Eloquencer executes is:
- Read CV INs
- If CV IN assignment is related with 'CV out' add the 'CV in value' to the 'nominal CV value' of the desired track, change this value in the CV output and rise the Gate.
Following this sequence it is not possible to use 'CV in' to transpose 'in time'.
Another approach could be to do it internally as @another_user proposes: caché both sequences and put it together, the problem is that there is the possibility that 'master transpose track' is not a static sequence, it could be modified by probability, it could be modified by another CV in...
I could say: if this link is created you override (in the master) all the probabilities and things that can modify a sequence, but then the behaviour will be inconsistent. The track parameters/modifiers need to work always the same way, to activate a feature should not de-activate other features.
@larsdaniel proposes to change the CV to the final value once the trigger has occurred but this could imply new problems, if the slave track is going to a digital module, let's say a digital oscillator, it will read the voltage when the trigger is received and then won't listen to the CV change.
I'm sure there is a solution for this need, but not sure yet how to solve it.
I'm sure there is a solution for this need, but not sure yet how to solve it.
that sounds great!
That sounds like what I imagine someone who created such a great device as the Eloquenzer should do with the users' requirements, even if they deviate somewhat from the original concept. 🙂
Really, I think there must be a solution, or one can be produced, if you set out to solve such a task.
The benefits that can be derived from it -for the user- are certainly immense.
Of course, I also see that it has to be profitable for you, the entrepreneur. After all, such a problem solution costs money. That has to come from somewhere.
Please don't misunderstand me, I like the ELO, I like _playing_ with it, I like finding solutions for the tasks that come about through my own ignorance "in relation to modular".
So I also like it when you make comments like the one quoted above.
It really sounds better than just "that's not possible", "we don't have that on the list", or "that deviates from the road map".
Please keep up the good work on good modules. I certainly want to keep buying your modules, and spending my time finding bugs. 🙂 That's just me.
Hi @another_user !
I understand your point of view.
When I say "that's not possible", "we don't have that on the list", or "that deviates from the road map", there is a reason behind. It is not me (or people helping me with design) saying 'I don't like to do this' or 'I don't want to do this' Sometimes it can be a real 'is not possible', for example due to hardware restrictions, or a processor power restriction. Sometimes can be something far away from the main purpose of the sequencer.
Since the beginning we have tried to implement as many suggestion as we can, and this have done the sequencer better, even before being a commercial product, while being just a personal project the Eloquencer has been nourished from many people ideas (Befaco, Miguel EEDL, Barcelona crew...).
As I mentioned in another post I'm partially working on the new update, but most of the resources are being spent by the new module ( that I can say is amazing ! 🙂 ). I have new things ready, what would you prefer ? a new beta version with some fixes and new stuff? or wait until final release ?