Samelot

**Samelot**

Hello, I'm a little lost here. What i'm trying to do is figure out a way to play a midi file back in a Vanilla PD patch

https://www.mail-archive.com/pd-list@iem.at/msg27247.html
After I read my midi file, looks like:

setparam 0 Time 0 0 999999 0 1000 200 0;
setparam 1 Pitch 0 0 127 60 12 4 0;
setparam 2 Vel 0 0 127 64 12 4 0;
setparam 3 Dur 0 1 99999 200 800 200 0;
setparam 4 Chan 0 1 16 1 8 1 0;
setparam 5 Track 0 1 32 1 8 1 0;
setparam 6 X1 0 0 999 0 80 20 0;
setparam 7 X2 0 0 999 0 80 20 0;
restore;
450 78 96 250 1 2 0 0;
250 78 96 250 1 2 0 0;
250 78 96 250 1 2 0 0;
250 78 96 250 1 2 0 0;
stop;

I figure out what to do next.

In the bottom left corner there is this object
[ route noteon noteoff polypressure cc pgm pitchwheel ]
and it says to copy/paste these commands to possibly filter the data that I want to be played. That's my only idea as of right now. Other than that, I'm completely lost.

**Samelot**

Hello, I'm currently working on a patch for pure data, so that I can use my Gladiator VST with a more mouse free approach. I am programing this patch to work with osculator inside Ableton Live.

The first thing I did was I made two buttons on my midi controller increment and decrement the first wave form in Gladiator (Osc1 Wave). Researching people trying to do this same thing for the tempo control in Ableton, I was able to find a patch that did this by making use of the moses object. So briefly, what each button is doing is sending to PD from Osculator and then incrementing or decrementing the moses object and then sending information back to Osculator through one midi message (ctlout 1 1). This message is than sent to Ableton and the Gladiator VST.

This has been working pretty great, and I'm fairly pleased, but there are some fine tunings I need to do in order to get it perfect. The Osc1 Wave slider goes up from 0 to 1000, and oddly, there are only 163 waveforms. So from 163 to 1000, the waveform just stays at waveform 163. When I first map [midi 1 1] in osculator to Osc1 Wave in gladiator, as I increment and decrement with my midi control, the intervals are by 16, which is bad because I skip 15 waveforms or so with every interval. To reduce this interval, I set the min and max of the midi message 1 in Ableton (which holds gladiator vst) from 0.0 - 1.0 to 0.0 - 0.17. This has made my interval mostly 1, with the occasional 2, skipping a waveform.

Ex: 0, 1, 2, 4, 5, 6, 8, etc.

I have done some research in an effort to solve this problem which I believe has something to do with translating/scaling the standard 127 midi range to a different range. I have messed around with strings such as:

|
|
[/ 1000]

but had little luck, and I'm not sure if this would even be in the same realm as my problem.

I'm attaching my osc and pd files, let me know if anything is unclear.
Thanks!

http://www.pdpatchrepo.info/hurleur/tempo4.pd

**Samelot**

Hello, I'm currently working on a patch for pure data, so that I can use my Gladiator VST with a more mouse free approach. I am programing this patch to work with osculator inside Ableton Live.

The first thing I did was I made two buttons on my midi controller increment and decrement the first wave form in Gladiator (Osc1 Wave). Researching people trying to do this same thing for the tempo control in Ableton, I was able to find a patch that did this by making use of the moses object. So briefly, what each button is doing is sending to PD from Osculator and then incrementing or decrementing the moses object and then sending information back to Osculator through one midi message (ctlout 1 1). This message is than sent to Ableton and the Gladiator VST.

This has been working pretty great, and I'm fairly pleased, but there are some fine tunings I need to do in order to get it perfect. The Osc1 Wave slider goes up from 0 to 1000, and oddly, there are only 163 waveforms. So from 163 to 1000, the waveform just stays at waveform 163. When I first map [midi 1 1] in osculator to Osc1 Wave in gladiator, as I increment and decrement with my midi control, the intervals are by 16, which is bad because I skip 15 waveforms or so with every interval. To reduce this interval, I set the min and max of the midi message 1 in Ableton (which holds gladiator vst) from 0.0 - 1.0 to 0.0 - 0.17. This has made my interval mostly 1, with the occasional 2, skipping a waveform.

Ex: 0, 1, 2, 4, 5, 6, 8, etc.

I have done some research in an effort to solve this problem which I believe has something to do with translating/scaling the standard 127 midi range to a different range. I have messed around with strings such as:

|
|
[/ 1000]

but had little luck, and I'm not sure if this would even be in the same realm as my problem.

I'm attaching my osc and pd files, let me know if anything is unclear.
Thanks!

http://www.pdpatchrepo.info/hurleur/tempo4.pd

**Samelot**

Hello, I'm currently trying to get better at using Osculator and pd in unison. I'd like to start working on PD tutorials, but I want to always have them running in and out of Osculator. Could anyone with experience in either PD and/or OSC let me know if I have done my code between them effectively and without redundancies...

Osculator file:
I start off in Osculator with creating a manual message "/ya/1" with an OSC Routing of localhost:9000.

PD file:

receiving code

sending code (separated from my receiving code)

(message) connect localhost 9000
|
|
(object) udpsend

(message) disconnect
|
|
(object) udpsend

...So when i test the /ya/1 message in Osculator with my mouse, I get the /ba/1 message added to Osculator. As I continue to click with my mouse, both of their activity boxes light up green in unison.

I'd like to know if this coding between Oscualtor and PD is efficient enough to move on with practices and tutorials in PD?
Is there a way to code udpreceive and udpsend interconnected rather than separated as seen in my PD file?
Should Osculator have two messages that are OSC Routing rather than one?

Let me know if anything is confusing or in need of clarification. Thanks!

http://www.pdpatchrepo.info/hurleur/sp1.oscd

**Samelot**

Hello, I'm currently trying to get better at using Osculator and pd in unison. I'd like to start working on PD tutorials, but I want to always have them running in and out of Osculator. Could anyone with experience in either PD and/or OSC let me know if I have done my code between them effectively and without redundancies...

Osculator file:
I start off in Osculator with creating a manual message "/ya/1" with an OSC Routing of localhost:9000.

PD file:

receiving code

sending code (separated from my receiving code)

(message) connect localhost 9000
|
|
(object) udpsend

(message) disconnect
|
|
(object) udpsend

...So when i test the /ya/1 message in Osculator with my mouse, I get the /ba/1 message added to Osculator. As I continue to click with my mouse, both of their activity boxes light up green in unison.

I'd like to know if this coding between Oscualtor and PD is efficient enough to move on with practices and tutorials in PD?
Is there a way to code udpreceive and udpsend interconnected rather than separated as seen in my PD file?
Should Osculator have two messages that are OSC Routing rather than one?

Let me know if anything is confusing or in need of clarification. Thanks!

http://www.pdpatchrepo.info/hurleur/sp1.oscd

**Samelot**

@mod said:

if you MUST output more than 128 steps with a single midi CC, then you can send two CC messages in a row, in much the same way as using two separate CC's.

so for example, 0, 100 would correspond to a value of 0 x 128 + 100 = 100
and then 1, 100 would correspond to 1 x 128 + 100 = 228

etc

does 0 stand for midi cc? and what does 100 stand for? Would the intervals being jumped here be 100, 228, 484, 612, etc? Wouldn't that be far to big a gap?

Thx

**Samelot**

@Maelstorm said:

This is just something that isn't going to happen with a single MIDI cc value. You only get a resolution of 128 integers with MIDI, which obviously is not enough to completely cover 163 waveforms.

I never got deep enough into Live to see if this is possible, but if you can use two cc messages to control a parameter, then that might work. The idea is that one MIDI cc is the least significant byte and the other is the most significant, and when put together they can represent a range of 128*128=16284 values (this is often used for pitch bend).

So would it be, in this case, that all values up to 163 would be covered (each gotten to by skipping 1 integer), and then there would just be a large quantity of extra left over (164-16284) which you simply wouldn't use?

I'm also a bit confused on the least significan and most significant byte.

Thankyou

**Samelot**

Oh ok, I was unaware of that. A mixture of doing this and rewriting my osc code seemed to fix the problem. Thanks

**Samelot**

So I'm getting an extremely frustrating error with my Pure Data code after reopening my documents this morning...

I haven't changed a thing, and now when I open my files and click on the signal to trigger Pure Data from OSC, I get the error "udpsend: not connected". I am very confused to why things could change like that, even after not doing anything. Could anyone suggest possible issues that may be causing this to happen?

**Samelot**

thanks, I will check it out now