IanniX glissando
Hi all,
I have recently started using IanniX 0.9.20 beta with Purr-Data on Ubuntu 18.04.
In IanniX I can draw a curve, add some triggers along its path and send their x, y coordinates in a patch of pd and convert them to sounds (sine wave oscillator). Everything works fine. When the cursor encounters a trigger, I have a sound of a certain frequency.
The question is this: what is the correct way to get a continuous glissando that follows that curve? (in Xenakis style).
Thanks,
a.
@atux The OSC data you get from Iannix (on port 57120?) includes the curves.
separating them from the other data depends on whether you are using the MrPeach library so [route /curve] or for vanilla [oscparse] >>> [route curve]
[route /curve /trigger] or [route curve trigger] will give you both curves and triggers.
You will probably need the transport messages too so as to stop playback when you stop playback in iannix so [route curve trigger transport]
Then unpack the curve data [unpack s f f f f f f] and I think the 2nd 3rd and 4th outlets are xyz.
Actually you will probably need a timer in Pd...... "I have not received a coordinate in x mseconds >> stop sound" to kill the glissando when the curve ends.
Maybe you have to tell iannix to send the curve data....... I can't remember.
David.
A short note here: if you use vanilla [oscparse], you must use [list trim] too, so:
[oscparse]
|
[list trim]
|
[route curve]
@whale-av said:
using the MrPeach library so [route /curve]
Thanks,
in this patch:
in the right side I use [route /trigger] : it works fine, no problem with triggers.
In the left side I use [route /curve]: from [unpack] no x, y value comes out, the box numbers remain stationary at zero.
But...the good thing is that [print] gives the coordinates of the points on the curve:
This means that the x,y data enter into Pure Data. But I can't get them to enter the box numbers.
Maybe something is missing?
Thank you,
a.
P.S.: I use Purr Data version 0.28.1 compiled against Pd-l2ork version 2.17.0, compiled against Pd version 0.48.0,
IanniX 0.9.20 beta on Ubuntu 18.04.
@atux Because it is /cursor in the message, not /curve?
@jameslo said:
@atux I think @ingox is suggesting you try changing [route /curve] to ]route /cursor] to match the path that's printed in the Purr Data console.
You're right, thank you... 
Now replacing [route /curve] with [route /cursor] it works. Sound is fine too.
I was just wondering how I can control the distance between one point and another so that the glissando always remains continuous and does not become, in some parts, a rapid scale of discrete values.
How can I get this?
Thanks,
a.
@atux Use [line] or [line~] and play with the time until it sounds smooth. 20 mS is a good place to start with the latter.
Now it works fine, both for triggers and for curves and cursors.
One question: using curves in IanniX, for example this bifurcation made of two different curves, the horizontal segment + the ascending segment has ID 3; the descending branch has ID 4:
in puredata how do i get both branches in output?
If I convert to sound in Purr Data (sine wave oscillator), I can hear the horizontal segment and then only the descending branch. In general, how can I "sort" the data of all overlapping curves the cursor encounters, so that I can then hear the sound of them all?
Maybe I need to add something to [unpack s f f f f f f]...
This is the current patch:
Thanks,
a.
@atux I don't know IanniX, but I'm guessing that the data for the upper and lower traces have to be identified in the OSC messages. Can you show the print output from the console?
@atux OK, the number following the /curve path looks like it's the segment ID, so that's how you distinguish between the upper/lower traces. I'm not sure where the type mismatch is coming from, but the expected types are specified in the [unpack] arguments. In the same way that the segment ID is typed as a symbol ("s") I wonder if any of those zeros are also typed unusually? I also wonder if the [2] in front of "error" gives any hints? (I don't know Purr Data)
@atux @jameslo The error in the console is my fault.. in my post above.
I forgot that I had always used the curve number (ID) to route to a specific abstraction before the [unpack s f f f f f f]...... I think.... it was a long time ago...!
So after a [route curve/] the unpack should in fact be [unpack f s f f f f f f]
The message is.....
curve ID groupID x y z time y-position z-position
symbol "curve"
float curve number (ID)
symbol (group ID)
float (cursor) collision value X
float collision value Y
float collision value Z
float (time) collision X position
float collision Y position
float collision Z position
.... the "positions" are on the iannix graph..... so maybe for visuals.... and I think scalable.... see the inspector ... infos (not a typo)..... messages tab.
.... I assume that unless a group name has been assigned to a bunch of curves the groupID will be an empty symbol and so it doesn't print.
You can get [rawprint] from the "zexy" library and that might well reveal it.
The simplest way to differentiate between the two curves will be to make the bottom or top branch a new curve with a new ID...... say start and bottom branch id1 --- top branch id2
then you can
[route /curve]
|
[route 1 2]
with a couple of [unpack s f f f f f f]'s on the outlets as the ID has been removed from the list.
Then replicate your audio generating patch on the second outlet.
David.
@whale-av said:
So after a [route curve/] the unpack should in fact be [unpack f s f f f f f f]
Yes, now output is error free. This is the beginning of the branching:
Now I try to get the simultaneous output of multiple curves.
Thank you,
a.
@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.
@whale-av said:
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 works!
Using [print] I saw that x, y come out of the second and third outlet:
Now I hear both branches in glissando at the same time, as I wanted.
Soon I will study the things you advised me.
Thanks,
a.
P.S.:
Yes, I purposely differentiated the ID of the two branches because, in more complex scores, the aim is to have control of the timbre (and other things) of each part.
@atux Yes...... x and y then come from the second and third outlets because when you use [route 3 4] the first float in the message f s f f f f f f is removed during the route...... in this case the 3 or 4 is removed and used to designate the first or the second [route] outlet.
If the value of the first float was other than 3 or 4 the entire message with that value still attached...... i.e. 7 s f f f f f f would drop from the last outlet of [route]..... the "unmatched" outlet.
David.
Oops! Looks like something went wrong!
