GEM replaced Ofelia in Plugdata
@Aliam.Sigsaly the maintainer of pdlua is Albert Gräf. The way open source software works is that one person can use the code from other projects (provided the licenses are compatible). This is called a 'fork' and it doesn't imply that the original project is being 'taken over' or 'annexed' by the fork.
Afaik there are feature request github and discord forums/channels for plug data if you want to discuss the direction of the project (though I suppose this could also be an appropriate venue).
Imo your expectations for an announcement on arbitrary channels for a certain library version not being supported anymore are slightly unreasonable.. I would say that if you want to be informed of plug data or development about a certain version of ophelia there are places to follow in order to do so.
I also don't think it's productive to talk about how superior m4L is unless you're making specific feature suggestions for the project you want to use in a productive and collaborative way.
edit: also, a great thing about open source is that if you don't like the direction of a project you are free to make your own fork and add or remove whatever aspects you wish. The maintainers have a right to include or omit features and library for whatever reason though you are of course free to make criticisms or suggestions (though I have to say your tone did come across as somewhat entitled, rather than collaborative.. for instance you could enquire why something might not be maintained anymore before catastrophizing). But if you want a certain feature without doing the work to implement it that can come across as expecting free labor or agreement on aesthetics.
edit2: personally I disagree with alexandre's "everything in 1 lib" philosophy for else (personally I like using many different established libraries that already have equivalent objects) but he does work hard on it and those aspects have driven its adoption in plug data and many other projects. Also he probably (would have been) open to improvements for it in general if you considered them to be lacking and had made pull requests to improve it or at least given suggestions or feature requests instead of/before complaining..
Poor performance in Sequencer
@ionicle I agree with oid....... windows wish is not great.
To make up for my bad post above....... here is your patch using abstractions...... seqo.zip
It automatically saves your patterns, and you can easily add more drum sounds without the screen becoming cluttered.
You might find it hard to understand how the abstractions work. There is some help for that here...... https://forum.pdpatchrepo.info/topic/9774/pure-data-noob and then especially further down that thread... here....https://forum.pdpatchrepo.info/topic/9774/pure-data-noob/4
Once you understand the use of abstractions you will be able to build patches faster and more easily..!
David.
phasor-makenote connection
@mkdewolf I recommend you take a step by step approach from the bottom up rather than from the top down because the first way you only have to learn one small thing at a time whereas the second way you have to learn many things at once. If you approach it this way then if something goes wrong at one of those small steps, you can just examine the few things you added or changed to find where the problem is.
Start by simply controlling [phasor~] with a frequency slider. Put a number display box between your slider and the phasor so you can see what's going on. You will immediately notice that frequency is different than pitch, and that a frequency of 10 sounds more like a beat than a tone. Next you could look for a way to convert a pitch number (i.e. MIDI) to a frequency. @nicnut suggested something you could use. Next take a look at that tutorial I suggested in your other topic, A02.amplitude.pd. The key insight here is that you can make the note turn on by taking the volume from 0 to some positive value, and the positive value it ends up on represents velocity. Conversely, you can make the note turn off by turning the volume back down to 0. The timing between when the note turns on and when it turns off is your duration, so you would next need a way to automate that. A delay from when the note turns on is one possibility, but you've already discovered [makenote], so that's another way. @nicnut's suggestion, setting the frequency to 0 after some delay, is another possibility for note off but I'd bet that it has side effects you wouldn't like. (Or maybe you would--that's up to you!)
Even if you do all these steps, the result will still be pretty crude, but you can continue refining one bit at a time and get closer and closer to something good at each step. You can get ideas about how to refine your patch by looking at some of the other tutorials, e.g. C10.monophonic.synth.pd and J08.classicsynth.pd. Once you have something that you like well enough, then you can add note-velocity-duration sequences (maybe using [text] as @whale-av suggested in your other topic), and finally, you can work on generating sequences that are serialized.
PS: if you're really only interested in serialization (and don't really care about making a synth from scratch) then there are other options available to you. Reply if so and then I or someone else can suggest alternatives.
How to keep number until turn knob
@ytt Perhaps this? It lacks the fault of the [expr] version which can leave you not being able to reach min or max rotation without altering the other value but it means the knob does nothing until you reach its old value. Error in the pic ([i] and [change] are reversed) but fixed in the file.
knob.pd
Edit: The [i ] -> [change] might be less then ideal and may not work at all depending on the output of your knob, if it outputs a float between 0 and 1 then this will not work as patched. Few different ways to fix this issue, depends on what exactly pd recieves from the knob and what your needs are.
How to keep number until turn knob
it gets in the weeds - basically you got a problem if your knob isn't a digital encoder which sends things like +1 or -1 to move numbers - typically these also have a push button.
if your knob is a potentiometer/slider/knob/pot like on an electric guitar - these only give discrete values and will Jump like on the left.
if you use one of those like I am on the right - and I apologize for it seeming messy, I'm cleaning up little problems - but the knob is still a potentiometer, so even tho I changed it into something that compares if its going higher or lower it ends up at weird places - so to do it right these needs to be an encoder type of knob - (which I'm simulating by just hitting the 1 and -1, a little surprised acting like an encoder isn't in [knob] yet.)knob-problems-pot-vs-encoder.pd
How to create a multi-mode knob?
I've been building some patches for the Befaco LICH modular platform which has potentiometers for the parameters that come through the framework as floats in [0-1]
Having run out of knobs on the LICH... I'd like to make it multi-mode so that each knob can control multiple-parameters, one per mode. The knob should remember (and output) each modes' value as the modes are changed. In the event that the knob and it's value get out of sync, it should have a simple way to re-sync the control, like turn it past it's previous value to re-sync.
I have a couple "working-ish" versions but I feel like I'm working too hard at it (against the system?) and there is a more straight-fwd approach that I am not seeing. Does anybody have any experience or thoughts on handling a multi-mode parameter gracefully and implementing it in Pd?
IanniX glissando
@atux Well...... that is good because it looks like one branch has automatically been given a new id..... or you did that and didn't realise.
So.....
[route /curve]
|
[route 3 4]
| |
[unpack s f f f f f f] [unpack s f f f f f f]
and duplicate your audio generator after each [unpack]
It is time for you to learn about abstractions...... unless of course you already have......
https://forum.pdpatchrepo.info/topic/9774/pure-data-noob
I might revisit that post as the examples are hard...... maybe give it a cursory read and then read.....
https://forum.pdpatchrepo.info/topic/9774/pure-data-noob/4
.... because you can save the audio part of your patch as [glissando] and then put in your main patch [glissando 3] and [glissando 4]
Outside the abstraction
[route /curve]
| |
[glissando 3] [glissando 4]
Inside the abstraction
[inlet]
|
[route $1]
|unpack s f f f f f f] and the rest.....
As you add more curves you can add more [glissando x] to the master.
I will probably build a new tutorial using your patch...... as it will be much easier to demonstrate to a beginner.
Beware.... you will need a volume control as all the [dac~]'s will add together so if you have a lot of curves you will overload the output or your ears......
Use [throw~ out] instead of [dac~] in the abstraction and a [catch~] in the master patch before a volume control.
David.
Midi Rotary Knob Direction Patch/Algorythm?
@oid said:
@Bangflip
Edit. you are trying to emulate a relative encoder with an absolute encoder, which will not work well, you will run out of knob, depending on the parameter you are editing and the knob movements you make, the knob could very well end up at min or max even though the parameter has not. You would probably be best off updating the knob value after every change, set to midvalue, detect change, determine if it is up or down, set back to mid value. Also make sure your controller can not be set to relative values for the encoders, many can and then all this will be unneeded.
Thank you for your answer. Id did know moses already, it is very helpful. Unfortunately the Houston only is sending absolute values: "The 8 x Rotary-Encoders send MIDI ‘Controller’ MSB/LSB absolute position". There is no option to change that as far as I know. It is an 20 years old controller and the support was dropped years ago.
Yes exacly. I am updating the knob value after every change. But I struggle to get the the up, down detection.
Midi Rotary Knob Direction Patch/Algorythm?
@Bangflip
Edit. you are trying to emulate a relative encoder with an absolute encoder, which will not work well, you will run out of knob, depending on the parameter you are editing and the knob movements you make, the knob could very well end up at min or max even though the parameter has not. You would probably be best off updating the knob value after every change, set to midvalue, detect change, determine if it is up or down, set back to mid value. Also make sure your controller can not be set to relative values for the encoders, many can and then all this will be unneeded.
Midi Rotary Knob Direction Patch/Algorythm?
Hey everybody,
Sorry, for a lot of text. But the bold text at the bottom is my main question. The rest will help you to get a better understanding of my situation.
you helped me so much, with my last question here (the Faders are working dope now):
https://forum.pdpatchrepo.info/topic/13849/how-to-smoothe-out-arrays/25
I am doing a Steinberg Houston to Mackie Control emulation at the moment, to use my controller with other DAWs than Cubase/Nuendo. Will upload it to the internet community, when I am finished for the handful of people that maybe are also using this controller.
I made good progress:
I got the Faders and the normal knobs to work. And the display puts out information. But it is with bugs, because the LCD Screen of the Houston has 40 characters for one line and the Mackie Universal Pro has 56 Characters. So i did a list algorithm, which deletes spaces of the mackie message until the message fits on the 40 character line. Maybe there is a method wich will work better but this subject eats too much time for me at the moment and it works rough okay. One defenitely get's some helpful information on the screen from the DAW.
The Faders and Rotary Knobs and normal knobs are the most important of this controller I guess. The Faders are working fine as I mentioned above, but there is a problem with the rotary knobs, wich I can't handle alone and hope you can help me.
The problem is, that the Mackie Controller send simple clicks to the DAW. If you are turning a rotary knob, it sends out a number of midi messages:
If you turn it right, it sends midi messages wich contains the value 1 and if you turn it down it sends messages wich are containing the value 65.
"When the VPots are rotated rapidly, a message equal to the number of clicks is sent."
BUT the Houston controller instead is sending values like it's faders with 15 (MSB) and 128(LSB) values. AND it is updating the rotary limit by itself. So if I turn a rotary, it will update it's LEDs and stops sending midi messages when it reaches the maximum or minimum value. So, I did this patch as a momentary state:
The DAW sends 11 values for the Houston LEDs. 11 is max and 1 is min. This is good, I send this values to my houston controller and can update the rotary values and LEDs.
With this updated values from the DAW, I can force my rotary knobs, that they don't stop to send values, because they are set to the values, which the DAW sends, every time I turn a knob. With this method I got it to work to imitate a Mackie Rotary knob. Everytime the Houston Rotary value changes, it sends Mackie "midi click values" according to the amount of midi value changes of the houston.
BUT the problem is, that this is working only in one direction. Now my main question:
How can I make pure Data know, if I am turning my knob in the left direction or in the right direction? There is also the problem, which I mentioned above, that I set the momentary value everytime, I move the rotary, so that I get a unlimited amount of possible rotary move "clicks". Also the midi values which the houston sends arent perfect smooth. It works fine, but it isn't like that, that if you move a rotary in one direction, every value one by another is perfectly lower or higher.
I think I maybe need a algorythm, which looks if the values in a time period are getting higher or lower and then send out bangs on two seperate outlets. For example the left outlet for lower values and the right outlet for higher values. And it should also detect, if I move the rotary fast or slow. So a constant smoothing or clocked bang is also not an option. This is defenitely to complicated for me. I have no idea and what I tried didn't worked.
Would be super cool, if you could help me out again.