it's been done before but this was my take on a simple way to livecode with [expr] in pure data - it leans into being as simple as possible so its easier to take it and use it for something else (bytemidi, drum triggers, using [expr~] instead for rampcode(?)).

a thing c and [expr],[expr~] share in common youcanwritefunctionswithoutanywhitespace so there didn't have to be any messy patching dealing with that - as an example it's being used for bytebeat (with some caveats about floats and things that [expr] doesn't like like sending it 0 with [value] at audio rate. It's pretty easy to change up - for example - pick a new big number and small number to the [mod ]s and you can make triggers for a sequencer. you could modify it to be [expr~] by changing the [message< , could stack more livecode inputs to control other things like the update frequency. anyway

https://patchstorage.com/bytebeat-and-dynamic-repatching-pd-as-a-livecode-environment/

"this is an experimental way to allow dynamic repatching in PD and do livecoding just using pure data.

livecoding requires – 1) an obscure language – pure data is a dataflow programming language 2) an obscure text editor – well I cant think of a more arcane one than a visual programming language so check that off for pure data too.

Known limitations – it’s a little crashy – the List message box doesn’t like backspaces.

32 bit floats lose precision and can make it a seem a little wonky – not all patches will sound the same because Pure Data uses 32 bit floats for effeciency. so objects with / % >> will effectively “chop” off and the patch will sound different than a real bytebeat (or whatever you use this for) after a while or seem like it can just plain quit. The numbers either got too small or too big to work with 32 bit floats.

Another thing about 32 bit floats, the biggest number PD can count to is 1.6772e+07

Pure data also squashes numbers you get 123456 digits. 1234560 turns into 1.23456e+06. In comments this gets changed after you close, reopen so try cut/paste.

Also I noticed sending 0 into [expr] in the variables makes it unhappy and crash so I avoided it making x and y 1 or bigger.

Anyway – check out

to see it in action – and if you want o use this for something else remove anything connected before and after the spigot objects.

public domain / unlicense / fishcrystals out"

pasting the same patch here: dynamicsinPatchingBYTEBEATeditionNewest.pd

dno about all the terminolgy and requirements, but it makes me happy when I see other people being creative and livecode has been a way to get people into doing experimental computer audio and video - probably after working where work is on the computer , personally I saw it as a way to rapidly prototype & it was my very first idea about something I wanted to do with bytebeat and pure data (only took a year! lol) - thanks to everyone in the community & the discord and netpd for making stuff and being helpful and being inspriring

Great!

I think you don't need the connection from Pd to the PulseAudio JACK Source. This is mixing Pd's output with the mic and then providing this to Pulse apps' mic input... I'm guessing this isn't what you meant.

• system:capture --> PulseAudio JACK Source (mic available in Pulse apps, good)
• system:capture --> Pure Data (mic available in Pd, good)
• PulseAudio JACK Sink --> system:playback (can hear Pulse apps)
• Pure Data --> system:playback (can hear Pd)

... at this point, you're finished -- you've got all the connections you really need. Anything extra is likely to be confusing later, so:

• Pure Data --> PulseAudio JACK Source (Pulse apps can hear the mix of the mic and Pd, but cannot get the solo mic signal anymore, probably a bad idea except for Zoom meetings about Pd)

hjh

Also: Maybe look in the OS for security settings about the built-in mic.

On all my previous Linux machines, the built-in mic worked with no problem.

My current machine, I get nothing from the built-in mic, but I do get a signal from a headset mic plugged into the phone jack. I don't know if this is a configuration problem or if the built-in mic is disabled for security reasons... the headset mic is fine for my casual-use needs (obviously in a pro audio situation, I'll use a real mic with a USB soundcard, I'm not that lo-fi) so I'm not going to investigate, but it just occurred to me today that it could be security.

hjh

Is the following possible:

Connecting dialectic mic to pd like that one or that one (does it need to pass through arduino? how can I first convert the analog signal to digital signal?

After receiving the signal in pd - is it possible to analyze the signal based on frequency and/or intensity ? so if the signal is at bandwidth x (between range of frequencies) it will trigger audio file x, if the signal is in bandwidth y it will trigger audio file y and so on

Is the above possible?

Thanks for any advising

Thank you both, first of all!

Worth to mention that I am using PD for the first time on a MacBook that I fresh reseted a month ago. No intentional manipulation of audio setting, ports and such has been done since. This Mac is fairly fresh and virgin. And it is working like a charm except for PD. All this considered, I am afraid that resetting now the SMC has few chances to solve the issue.

In our class there are 9 people, everyone with a different Mac. Only 2 of the 9 Macs had the latest OS (Ventura) and exactly these two Macs have similar problems (PD's GUI freezing or not responding as expected). This led me think that the problem may be somehow connected to the OS update. But this can also be just an absolute coincidence.

(...and no, unfortunately none of them will agree on updating their Mac's OS in order to help out finding what's the problem here, I can tell you already. Teacher even suggested them to not update the OS).

I attach the patch. As you can see this is just the first 5 minutes of a very first class on using PD. No settings where modified from the default and no complex patch content.
esercizio_001.pd

Indeed, as everyone I do have programs for communication (not Skype, but Zoom for example) although in that moment these were not being used at least not in the GUI. Consider though that I tried again several reboots and Zoom is not in my automatic startup launched apps.

@Riccardo-V Hmm.... unless you have made a patch that uses the microphone....... using an [adc~] object.... and then fed that back to the speakers using a [dac~] object.... I cannot see how it would be Pd causing this. Especially not after it has been stopped.

But if you are using a [adc~] fed to a [dac~] then you will have to use headphones as the microphone is too close to the speakers on a laptop and feedback is unavoidable.

Please upload the patch that is causing the problem......... using the
button above where you are typing a message into the forum.

I believe a Mac will reopen all programs that were running before you shut the laptop down? If that is so then try closing them all before running Pd again. Programs for communications.....like Skype.. might change some audio settings.
Check to see what has been using the microphone, and the sound settings....... https://support.apple.com/guide/mac-help/change-the-sound-input-settings-mchlp2567/mac
Also there is just a chance that resetting the SMC will help.

Bedtime here.... so I will be gone for the next 8 hours but someone else might have some ideas.
David.

@romulovieira-me Under preferences > audio> select your sound card's line input. If it is the internal sound card there shouldn't be very many options, just a mic and maybe a line input (depends on your OS). Generally it's default set to the mic. (https://puredata.info/docs/faq/audioinput)

Then in a patch, create an [adc~] object. Normally or initially, this is assigned to the mic on the computer, but if you have selected the signal line input from your soundcard you should be able to get a connection established. Getting the correct input and output set up can be the hardest bit of getting set up, stick with it and you'll find what is right for you. If you struggle with it, post a screenshot of your audio options and we can hopefully help point you in the right direction. If it's just a mono input, you may only have sound form one output of the [adc~] object. If you right click the adc object you can find out more, with examples etc. (you can do this with all patches, and is a great way to learn via practise.

You will still have to connect the input sound to the [dac~] object, which will convert your signal back from digital to audio. Be careful though, it will be at full volume, so it is always recommended to put an object before the dac that will lower the volume (0 is silence, 1 is full volume, so lower decimals of 1 are advised before you know what to expect, maybe [*~ 0.1] to start).

A small diagram to describe:
{adc~]
|
{*~ 0.1]
|
[dac~ 1 2]

explains how to do this if the audio input is selected as the computer mic, but if you change the selection you hopefully can find your guitar input (if you have an external sound card this will be a lot easier). Generally ASIO is recommended, as other basic sound cards can have very slow latency (particularly noticable if you're working with live physical instruments) and can crackle a lot too.

It's worth searching this forum too, as you might find a lot more tips and help.

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:

Rotary Encoder Example.pd

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.

@whale-av said:

@Bangflip Maybe you have seen this discussion...... https://discuss.cakewalk.com/index.php?/topic/19846-mackie-control-questions/

The Mackie control is supposed to spit out a direct linear midi slope...... Mackie Control Midi Table.pdf and only clockwise/counterclockwise and count for rotary encoders (like the BCF2000).

In the discussion above "skavan" has given an approximate formula for a linearization of the Cakewalk curve. Maybe there is other information out there or a question on a Cubase forum would shed some light.
Or maybe the curve is the same in Cubase as a lot of the software developers were moving around as Cakewalk folded.

Hey, thank you for the discussion link!

Also for the Mackie Control Midi Table. This link, I already knew, and is very helpful.

If you have jitter in the slope then make absolutely sure that you have no midi feedback anywhere in your setup....... I am a bit embarrassed to mention that as it seems you know what you are doing......
David.

I already made sure, that there isn’t any feedback. I also think it has maybe something to do with my configuration or the values, Cubase sends out, because the little midi drops are always the same with continuus raising of the Cubase Fader.

I am experienced with sound design, yes, but I am more a creative, not a technican or programmer. It‘s a project, to invest some time and learn pure data for me.

I am thankful for every tip.

@Bangflip Maybe you have seen this discussion...... https://discuss.cakewalk.com/index.php?/topic/19846-mackie-control-questions/

The Mackie control is supposed to spit out a direct linear midi slope...... Mackie Control Midi Table.pdf and only clockwise/counterclockwise and count for rotary encoders (like the BCF2000).

In the discussion above "skavan" has given an approximate formula for a linearization of the Cakewalk curve. Maybe there is other information out there or a question on a Cubase forum would shed some light.
Or maybe the curve is the same in Cubase as a lot of the software developers were moving around as Cakewalk folded.

If you have jitter in the slope then make absolutely sure that you have no midi feedback anywhere in your setup....... I am a bit embarrassed to mention that as it seems you know what you are doing......
David.