Best way to create random seed on [loadbang] with vanilla?
Just another thought on [random2]: It cannot be ruled out that it runs into a loop. I tested that a seed never produces the same number, but it can happen that a seed produces a random number that is used as the next seed that produces the previous seed – or that it happens later in the process. I could test it to some depth, but it is not feasible to test it for millions of random lines.
So it is probably better to go with the entropy approach.
If you have a seed range up to 10.000 you have 10.000 possible lines of deterministic random numbers and some may appear more often or even sometimes repetitions may appear, but there is not the possibility of an actual loop.
i/o-errors in pd
@JackPD Ok, looking at sndfiler. Let me see if I understand it correctly.
Take the following test patch:
[table foo 128]
[nbx]
|
[; A bang; B resize foo $1; C bang(
[receive B]
|
[sndfiler]
|
[bang]
|
[send SNDFILER_OUT]
[r A] [r SNDFILER_OUT]
| |
[timer]
|
[print first]
[r C]
|
[print last]
Is it true that I would get output printed in the order "last" then "first"? If so then sndfiler breaks Pd's depth-first message passing rule.
Is it true that [timer] here will output different values depending on the size of the float provided to [nbx]? If so then [sndfiler] breaks Pd's deterministic scheduling rule.
Also, it appears a "resize" message with no arguments would crash Pd. That's a bit alarming given that I just happened upon it while scrolling through the source. Threading issues are extremely difficult to debug so I'm a bit cautious about exploring much further. (Also there's a threading wrapper library dependency by yet another author...)
Just for a thought-experiment: imagine a set of "delay" externals that try to do computation on a separate thread in the time allotted:
[resize foo 256(
|
[sndfiler 50]
In this case "50" would mean to delay output for 50 milliseconds from the time the object receives an input. So you send the resize message, sndfiler does the work in a separate thread, and after 50ms the object gets a callback to send output.
Now, if the thread has finished its work the output would be sent deterministically. If not the object would block until the thread has finished, send the output, then display an error to the console that it missed a deadline.
That's basically just mapping Pd's system scheduling to control objects. I think that would be a very clunky design that would be hard for users to maintain and reason about. But it's still preferable to breaking determinism as sndfiler apparently does.
Btw-- even after sndfiler finishes its threaded array resizing, it still must rebuild the dsp graph for the reasons I mentioned in my last message. So for patches with lots of signal objects you'd probably still generate dropouts.
Hm... here's an idea:
- Require every class that deals with garrays to have a "set" method
- Require the "set" method of these classes to bind the object to a symbol that concatenates the array name with something like "_setter". So [set foo(--[tabread] would bind that object to symbol "foo_setter"
- When array "foo" gets resized, send a message "set foo" to "foo_setter"
Now every table-related object that uses array "foo" will have an updated reference to the newly resized array before the next dsp tick. This is because when you send a message to a receiver symbol in Pd it will dispatch the message to every object that shares this name.
On the other hand, the "set" methods of table-related classes in Pd weren't designed to be realtime safe. For example, some resize values may trigger an runtime error condition that requires rebuilding the graph. I guess the algorithm above could call some kind of "slim-lined" version of "set" that does size-based checks but excludes things like array name lookups, etc. But that would require splitting out every single "set" into a set of two methods.
A combination of that and the delay-based sndfiler could get you array resizing without dropouts. But that's a very clunky interface which is difficult to debug for a lot of work upfront just to get it running.
i/o-errors in pd
@whale-av: thats interesting.
Details about my system and configuration:
OS.: arch
pd-version: Pd-0.49.0 ("") compiled 17:22:56 Sep 26 2018
pd config:
audioapi: 5
noaudioin: False
audioindev1: 0 2
audioindevname1: JACK
noaudioout: False
audiooutdev1: 0 2
audiooutdevname1: JACK
audiobuf: 11
rate: 41000
callback: 0
blocksize: 256
midiapi: 0
nomidiin: True
nomidiout: True
path1: /home/samuel/.sgPD
npath: 1
standardpath: 1
verbose: 0
loadlib1: sgCLib/sgScriptLib
loadlib2: sgCLib/sgInputC
loadlib3: zexy
nloadlib: 3
defeatrt: 0
flags:
zoom: 1
loading: no
sound-server: jackd
jack config:
> jack_control dp
--- get driver parameters (type:isset:default:value)
device: ALSA device name (str:set:hw:0:hw:0)
capture: Provide capture ports. Optionally set device (str:set:none:hw:0)
playback: Provide playback ports. Optionally set device (str:set:none:hw:0)
rate: Sample rate (uint:set:48000:44100)
period: Frames per period (uint:set:1024:256)
nperiods: Number of periods of playback latency (uint:set:2:2)
hwmon: Hardware monitoring, if available (bool:notset:False:False)
hwmeter: Hardware metering, if available (bool:set:False:False)
duplex: Provide both capture and playback ports (bool:set:True:True)
softmode: Soft-mode, no xrun handling (bool:set:False:False)
monitor: Provide monitor ports for the output (bool:set:False:False)
dither: Dithering mode (char:set:n:n)
inchannels: Number of capture channels (defaults to hardware max) (uint:notset:0:0)
outchannels: Number of playback channels (defaults to hardware max) (uint:notset:0:0)
shorts: Try 16-bit samples before 32-bit (bool:set:False:False)
input-latency: Extra input latency (frames) (uint:notset:0:0)
output-latency: Extra output latency (frames) (uint:notset:0:0)
midi-driver: ALSA MIDI driver (str:notset:none:none)
root-priority: Hmm. I guess no. I'll try your suggestion, and see if it helps!
Configuration is pretty standard, I guess.
My impression is that certain events in my patch cause some messages being sent to multiple destinations, which causes pd to get out of sync.
It's slightly difficult to isolate the problem(s) into a small example, since I am using my own library of abstractions for parsing/generating recursively structured messages and automatically/dynamically connecting objects. I use this e.g. to let one object track properties of another one. It's nothing too fancy, all just native pd.
The amount and length of messages is still very moderate. It's disappointing to see pd struggle already.
(e.g. a "sample recorder" would record audio and update the "sample" object, by sending a "length" of the recording in ms, which in turn also distributes this message to ~3 "sample player" objects).
I will try to make a small example, that shows the issues I am facing.
Thank you for your help so far!
Any suggestions are welcome
ofelia lua table and a few questions
@cuinjune hi. "array get emulation" works but outputs the whole array, while with the pure data "array get" you can also set "first index to output" and "number of points". same for the pure data "array set" while the number of points is defined by the length of the input list and the array isnt resized (the set values are inserted).
array set emulation doesnt work for me, it just resizes the array (win10 pd64bit).
but should define a new array and not just insert some values?
here i tried to emulate pure data "array set" with the "setAt" method:
array_set_emulation.pd
but the last value of the list is always written to the last value of the array, doesnt matter which onset value is set.
i think because of the code in ofeliaBindings.h "n=size-1" which is meant for setting a single value?
void setAt(int n, t_floatarg f)
{
t_garray *a; int size; t_word *vec;
if (exists(&a) && getData(a, &size, &vec))
{
if (n < 0) n = 0;
else if (n >= size) n = size - 1;
vec[n].w_float = f;
garray_redraw(a);
}```
Lissa Executable / ofxOfelia compile error (Solved)
@cuinjune I tried to compile the lissa seq patch. but when i open the executable it opens only a small empty window.
i also tried to compile a help patch for testing, with the same result.
but your example works fine(Win32Example).
MobMuPlat OSC-to-MIDI Remote Control, spec. for PD, Guitarix, and Rakarrack and other guitar effects apps
It's always funny to me how working on one PD project results in fruit that might also prove useful.
Currently, working on a broader project, but this part (at least) (I think) is ready for distribution.
Background: I Really hate leaving the side of my guitar (for example to click a mouse or tweak a setting) when I am playing. So designed this mmp app so that I can attach (with funtack, ex.) my handheld to my guitar and control my settings from there or perhaps even as I play. Like so:
[Aside: the broader project also includes (on the front-side of the app) controls driven by the handheld's tilt, as well as, the adc~ pitch, env~, and distance of the pitch from a "center". But that part has to wait (though the code is all inside the mmp_osc2midi_rc.pd patch just disconnected/does not use the cpu).]
SETUP (linux is what I know, so other OSes may work just can't/haven't tested them):
JACK
Pure Data
a2jmidid - JACK MIDI daemon for ALSA MIDI (in the Ubuntu at least repos)
guitarix a/o rakarrack, or other midi-driven effects apps (such as the included set of 30 pd effects(see below))
PIECES:
The mmp_osc2midi_rc.zip (extract(android)/install(ios) to MobMuPlat directory)
The osc2midi_bridge.zip (to be run on the "pd receiver") and includes the osc2midi_bridge.pd, help file, and a set of 30 mmp-ready-(mono) effects (in the ./effs directory) that can be used if PD is to be used as the receiver. (They are standardized to include 3 inlets: left=inlet~, center=[0 $1(, [1 $1(, [2 $1( messages sent to 3 parameters on the effect, and right=[switch~] and 1 outlet~ and a demo guitarix "bank" file called "MIDITEST.gx" (which includes 2 presets/programs and set midi values (0-8) to test. Just add the file to the guitarix config "banks" folder).
Instructions:
- Start Jack;
- In Pure Data, open the osc2midi_bridge-help.pd file; toggle "listen" on; and set MEDIA to "ALSA-MIDI" (the additional pieces are just examples of receiving the midi values);
- In Jack>ALSA: Connect Read:MIDI to Write:PD & Read:PD to Write:Midi;
- From the command line execute "a2j_control start" (no quotes);
- Start (ex.) guitarix;
- In Jack>Midi connect a2j:Pure Data(capture) to (ex) gx_head_amp:midi_in_1.
Note/Alert/etc. For a machine to receive OSC messages the recipient-computer's firewall must (I believe) be turned off.
GUI:
The GUI has 3 pages that look (basically) as follows (with the subsequent 2 pages having only the 3 knobs and 3 buttons).
The buttons trigger text entry boxes which allow you to enter numbers (0-127) representing:
PGM: the number sent to (midi) [pgm]
and
(the buttons beside the knobs) the midi value, i.e [ctrl] (0-127), each knob is to be sent to (all on channel=0). (The resulting number of which are all written to the label to the left.)
For example:
Results in:
You can now to do 1 of 2 things:
Set the mmp-knobs to whatever midi values you have set in guitarix
or
Set the guitarix midi values (mousewheel click on a control) to one of the mmp preset 0-8 midi values.
WOW!!!
That took a helluva a lot of writing (and reading) but I hope you can both see the value and make use of this bit of technology.
As I said before,
I look forward to being able to fine tune my sound ALL while my hands and I are BOTH still at my guitar and not bend over, move, etc. etc. etc. to get the sound I want.
Peace, Love, and Ever-Lasting Good Cheer.
If you made it this far , Thanks for Listening.
Sincerely and Optimistically,
Scott
p.s. ask whatever you want regarding setup, how to use, points-of-clarification, etc. I am more than happy to help.
"Out of Love comes Joy"
Build a MIDI controller with the Arduino, Firmata and Pure Data
Time to start contributing some knowledge back to the wonderful world that is the internet; today, a step by step nice and easy tutorial on getting started to building your own MIDI controllers with the arduino.
When researching for my ableton controller project, I didn’t find much out there about using firmata on an arduino to send data to software. The standard approach just seemed to be create the code in the arduino language, upload it to your board and hack one of those MIDI to USB cables as a bodge job way of getting the MIDI out of the arduino.
So why firmata and pure data? Well the whole idea of firmata is that you flash it to your arduino, and it throws out serial about whats going on with the arduino inputs and outputs, then you decide how the software treats the readings coming in and going out.
Theory out the way, lets build some controllers. You’ll need a few things…
HARDWARE:
An arduino and something to wire into it (for this i’ll be using a pot)
A USB cable for your arduino
SOFTWARE:
Arduino – http://arduino.cc/en/Main/Software
Pure Data – http://puredata.info/downloads
Firmata – http://at.or.at/hans/pd/objects.html#pduino
Something to patch your new controller into; like Reason or Ableton Live
- SETTING UP FIRMATA AND PURE DATA
Install Pure Data and create a folder to store all your patches somewhere. Unzip Firmata and add the files ‘arduino.pd’, ‘arduino-test.pd’ and ‘arduino-help.pd’ to your new Pure Data folder. The ‘arduino.pd’ file is the object that we use in PD for opening up communication with your arduino and routing it to PD. Done? Awesome, your software is almost set up.
- FLASHING FIRMATA TO YOUR ARDUINO
Install the latest version of arduino and open it up. Connect your arduino with the USB cable to your laptop (i’m using a macbook for this by the way). In the example patches, open up “Standard Firmata”, select your board (im using an arduino mega), and your serial port (look for tty.usbserial for use with a USB cable). Then compile and hit the upload button and your arduino is now ready to use firmata and communicate with Pure Data!
- WIRING UP A POT
Potentiometers are cool, and theres a great arduino tutorial of how to wire one up here: http://www.arduino.cc/en/Tutorial/Potentiometer
Basically, all you need to know is that there are three pins; your two outer pins govern voltage flow across the pot, meaning one has to be 5V and the other has to be ground. It doesn’t matter which, but your 5v pin is going to be where your pot reads maximum, so convention dictates this should be the right hand pin. The center pin needs to be connected to an analog in on the arduino and will read the value of the pot as it sweeps from ground (0v) to 5v.
All wired up? Plug it into your laptop and open Pure Data, we’re ready to get things talking.
- SETTING UP OUR PATCH
Open the example “arduino-test.pd” Pure Data patch you copied over earlier. It should look like this one…
The test patch has everything we need to open a connection and enable pins. Firstly, lets delete a bunch of stuff and make our window a bit bigger. Hit Command + E to enter edit mode in Pure Data.
Ok a quick explaination; the key component here is the ‘arduino’ object. This is being drawn from the file you copied in earlier, and is what communicated with your arduino. Here we can do everything to control the arduino from opening a connection, to receiving data.
The large grid allows us to set the mode of each pin on the arduino. Remember pins 0 and 1 are reserved for Rx and Tx. I’m using analog pin 4 for this demo, so I’ve set my pin mode for pin 4 to ‘analog’.
Now we can plug our arduino in and get a reading from the potentiometer.
- ARDUINO INTO PURE DATA
With your arduino plugged in, hit command and E to bring us out of edit mode. In our patch, click on ‘Devices’ above the arduino object and open up the pure data terminal. (That other thing that loads with PD that has all the scary code in)
The “Devices” message connected to the arduino object pings your computer to find what devices are connected and on what serial ports. Since we’re using a USB cable to connect our arduino, we’re looking for something with ‘usbserial’ in it, in this case; port 2.
Select the relevent port in the green box at the top (remember the first box is ‘0’, second is ‘1’ and so forth) and hit ‘Open’ to establish a connection. Check the terminal to see if the connection was sucessful.
Now lets check we’re getting something in. Create a number box (Command + 3) and connect it to the relevent pin on the ‘Route analog’ box at the bottom. In this case, pin 4.
One more thing; if you’re not getting any readings in, you’ll need to click on ‘pd old analog/digital controls’ and enable your pins here too. What I tend to do in my patches is just not include the large grid but make my own ‘old pd’ controls custom to what i’m enabling/disabling to save space.
Here’s what the ‘old analog/digital controls’ subpatch looks like (pin 4 enabled)…
Come out of edit mode and check that you’ve got readings. If so congratulations! If not, troubleshoot, start with making sure your usb connection is opened, make sure all the correct pins are enabled (remember you’re counting from 0 not 1 on most of these buttons in PD, it’s just the way computers work).
- SCALING READINGS TO MIDI
So we’ve got a reading and chances are it’s to 3 decimal places between 0 to 1. No problem, create a new object (Command + 1) and type “autoscale 0 127”. This allows us to scale the input to a min and max value, in this case 0 to 127 of MIDI. Next, lets get things looking nice, create a new object and type “knob”. Connect this AFTER the autoscale object. (the knob is default set to read inputs from 0 to 127. Then create another number to display the scaled MIDI data coming out, and finally a new object and type “ctlout 1”.
It should look something like this…
The second box should be outputing values from 0 – 127 now, and the knob giving a visual representation of your potentiometer.
Now lets patch it into ableton…
- PURE DATA TO ABLETON LIVE
Firstly, you’ll need to set up your macs IAC driver if you’ve not done this. Basically you’ll need to go into Audio/MIDI preferences and enable your IAC driver. Then create a new input and output. One for input to DAW and one for output from DAW. Google around for a tutorial on this, its really simple, a 30 second job.
After you’ve set up your IAC driver, go back to PD and go to preferences > MIDI Settings, and connect your IAC driver.
Open ableton and go to its MIDI preferences. Create a device listing for your IAC driver and enable its ins and outs into ableton like so…
And thats it! Create an instrument and try to assign something! I’ve got it controlling the brightness of a bass sound here.
Shout out for Facu who requested this tutorial. Hopefully it’ll help some of you looking to get into this stuff and start building things but with no idea where to start.
markovGenerator: A music generator based on Markov chains with variable length
Edit: There is a general [markov] abstraction now at https://forum.pdpatchrepo.info/topic/12147/midi-into-seq-and-markov-chains/45
This is one of the early projects by @Jona and me. Happy to finally release it.
markovGenerator
Generates music from learned material using Markov chains. It is polyphonic, plays endlessly and supports Markov chains with variable length.
markovGenerator.zip (updated)
Usage:
- Record midi notes or load midi files
- Make Markov system
- Play
-
Record midi notes or load midi files
Until you reset the memory, each new recording will be added to the memory. The recorded material is seen as a loop, so that the last note is followed by the the first note, for endless play. markovGenerator handles recording midi and loading midi files differently: When you record midi, it will record notes according to the midi clock every sixth midi tick. This is defined in the counter in [pd midiclock]. So that way, breaks are being recorded and the rhythm is preserved. When loading midi files, no breaks are being recorded, the notes are just recorded in order, so the rhythm will be lost. In any case, simultaneous notes will be recorded as chords, so polyphony is preserved. -
Make Markov system
Set markovOrder to specify the length of the Markov chain. The higher the order, the more musical information will be kept, the lower the order, the more random it gets. You can use soundFilter and channelFilter to only use notes of the specified sound or channel. This is especially useful when working with midi files. Note that if there are no notes of the specified sound or channel, the Markov system will be empty and nothing will be played. Set the filters to zero to disable them. If you change the settings for the Markov system, click makeMarkov again for them to take effect. You can make new Markov systems with different settings out of the same recorded material over and over again, even when playing. If you record additional notes, click makeMarkov again to incorporate them into the Markov system. -
Play
While playing, you can change the note length, sound and midi out channel. Set soundOut and channelOut to zero to use the sound and channel information of the original material. Playing starts with the Markov chain of the last recorded notes, so the first note might be played first.
Use the markovAll section on the right to control all Markov channels at once. Here you can also set tempo, swing and midiSync, and you can save the project or load previous projects.
Have fun!
If it does not play, make sure that
- you recorded some notes,
- you hit the makeMarkov button,
- soundFilter and channelFilter are not set to values where there are no notes. Try setting the filters to zero and hit makeMarkov again.
About the Markov system:
You can see the Markov system of each Markov channel in [text define $0markov]. Notes are stored as symbols, where the values are joined by "?". A note might look like 42?69?35?10 (pitch?velocity?sound?channel). Chords are joined by "=". A chord of two notes might look like 40?113?35?10=42?49?35?10. Notes and chords are joined to Markov chains by "-". The velocity values are not included in the chains. Sound and midi channel values are only included, if soundFilter or channelFilter are off, respectively. Markov chains of order three may look like 42?35?10-36?35?10=42?35?10-60?35?2 with filters off and simply like 42-37-40 with both filters active, only using the pitch value.
Requires Pd 0.47.1 with the libraries cyclone, zexy and list-abs.
pd 0.47.1 change audio settings will hang program both on Mac and Windows
@leowang Yes, you are correct, my mistake.
I am using windows7.
I was in a hurry and didn't explain well. Try opening Pd from the [fix.pd] patch (Pd not already running)..... and then open media-settings, save and close............. and then see if you can change to what you wish.
I have 64 samples set (Block size) which is called Buffer size (samples) in my Asio4All driver. I have never changed that setting for Pd, but I have had to change it in the driver for some soundcards.
I am (almost) certain that the driver receives a 64 sample block size quite happily, and then you can set the block size for the cpu / outboard dsp in the driver settings. The driver does the block size conversion, and if you set the size too low in the driver then it will stall, or cause dropouts.
I have 2ms (Delay) set in Pd, which is called Buffer Offset in Asio4All. More Buffer offset, hardware or software, can be added in the driver if necessary.
But finding the low latency setting is all trial and error.
I have found that setting the offset (Delay ms) in Pd too low will cause dropouts, and setting it too high can cause Pd to stop responding. I think maybe Pd hangs when you open the Audio-settings window......... before you change the Block size......... and so the fix might help?
David.
pd 0.47.1 change audio settings will hang program both on Mac and Windows
@leowang Hello....... The audio settings should match the hardware of the computer. If you try to set the "wrong" settings it will hang Pd. but as every computer setup is different it is impossible to give advice. Beware.... Delay (ms) and Block Size are not called the same things always in asio and other drivers......
Also, setting too "tight"...... trying to set the latency too low will cause problems.
Here is a patch that will set the audio-settings back to a relaxed normal setup........ fix.pd ..... and then you can try again.
Open it and save the settings.......
It is useful if you get into a situation where Pd will not open properly either....... because of the audio settings...... or where in fact it has already hung as soon as you open the audio-settings....... which is why you cannot change them to the correct ones!
David.