• Mr_Slow

    Good info, thanks!

    posted in technical issues read more
  • Mr_Slow

    Unfortunately, I produce a lot and I know for the fact, that 5ms difference is perfectly audible if you deal with sharp transients. If you have two tracks of sounds meant to play together with prominent transients and peaks, 5 ms drifting would create a huge sonic difference.

    I will try the PDvst and see how stable and usable it is. I just can't bring myself to install and set it up properly, yet.

    posted in technical issues read more
  • Mr_Slow

    Thank you for the info.

    5 ms is quite a lot, in my opinion (as it could create a different feel in music when a lot of tracks is involved, or when transient control is the key).

    I still have not tried setting up PD VST but I suppose it should be the tightest way of generating MIDI into a DAW. What you think?

    posted in technical issues read more
  • Mr_Slow

    I simply need to send tight MIDI events and tight control events (FX automations, etc) to a DAW that will record it. I want to jam with algorithms in PD and be assured that it will be recorded exactly as I heard it during a jam. I would also like my DAW to be in sync with PD, but that is a huge problem...

    posted in technical issues read more
  • Mr_Slow

    @tomchaossen said:

    and by the way... not only in windows i changed to linux to get finally full control over what my system does, but still got a long list of things that have to be changed to be used as a serious "production tool"

    Can you name a few for a Windows user? This is quite demotivating to read, though...

    posted in technical issues read more
  • Mr_Slow

    Oh, I see! This makes a lot of sense. Thank you, Gilberto.

    I will have to come up with a different solution.

    posted in technical issues read more
  • Mr_Slow

    Thank you, Tom, I will check your suggestions.

    However, I am afraid syncing PD to an external clock (at least in Windows) will produce even more inaccuracies because the data have to be sent between two applications (and through the OS). Or am I mistaken?

    I can give it a try, though.

    posted in technical issues read more
  • Mr_Slow

    Hi, guys,

    can anyone please examine this simple patch and explain why is it causing hanging notes? I already tried few things with it and found out that when I disable adding of the random numbers, the note offs are working fine.

    So what is wrong? I believe the data flow order should be fine.

    This is the patch: HangingNotes.zip

    Thanks!

    posted in technical issues read more
  • Mr_Slow

    My issues are on Win7 Home Premium SP1.

    posted in technical issues read more
  • Mr_Slow

    I am, too, very unsatisfied with MIDI timing and stability in PD. It is my major concern and major argument for purchasing Max. I have not decided yet, though, as I still hope there is something that could be done in order to fix MIDI in/out behaviour in PD.

    posted in technical issues read more
  • Mr_Slow

    Hi,

    I have been wondering why is PD's MIDI output so jittery and why it has so many problems with note-offs not working properly (hanging notes every few dozens of notes, with fast sequences even more often).

    I have recently tested a simple MIDI out patch in Max 7 and its MIDI output is rock solid no matter what. No hanging notes, no noticeable jitter. It is the major thing that is making me considering purchasing Max 7 but I have also found out, during the testing, that it really crashes a lot while doing basic things so I would stay with PD if the mentioned MIDI output problems are fixable.

    Can there be anything done in/with PD that would make MIDI out solid as in Max 7?

    I really really want to love PD but this is a major bummer. I really need to output MIDI to a DAW.

    Thank you.

    posted in technical issues read more
  • Mr_Slow

    Fantastic, thank you!

    posted in technical issues read more
  • Mr_Slow

    Hi,

    I am not sure if this is a correct forum section to ask.

    I have tried using MrPeach's OSC to trigger the virtual MIDI keyboard in Reaper to record MIDI on a track.

    At first I thought this would get me much more precision in timing of the events than if I was sending simple MIDI from Pd. However, there is a lot of timing imprecisions in both beginning and length of the notes. I am using the loopback connection to send the data from Pd so it should be very fast and precise in theory. I have a fast CPU.

    I suppose the timing in Pd itself is rock-solid and it outputs the OSC messages with correct timing. So what else could be causing this very noticeable imprecisions?

    Any suggestions would be very welcome.

    Thank you

    posted in technical issues read more
  • Mr_Slow

    bump, I am very interested in this too.

    posted in technical issues read more
  • Mr_Slow

    OK, nevermind. There is no need to see the patch now.

    I will have to create another topic, because, clearly, number boxes are the performance heavy problem makers. The second number box type is even more hungry. I believe it is a bug in PD somewhere. Will have to investigate more.

    EDIT:

    OK, I take it back, it is not the number boxes but a fast update rate of values from one source distributed to multiple destinations. I have no idea if this can be solved efficiently without workarounds.

    EDIT 2:

    OK, forget about this completely. This is a GUI update problem. When I shrink the window of the patch, the performance is normal. It probably badly handles too many visually updating elements at once. I will try to decrease the font size or put the patch into an abstraction.

    posted in technical issues read more
  • Mr_Slow

    Anyway, the performance problems I had are now gone so I will stick with it and will see what comes nex.

    posted in technical issues read more
  • Mr_Slow

    OK, I have done some trial/error investigation on the patch and seems to me that the reason for the GUI freezing are the number boxes. For some reason, those duplicated number boxes showing the same values freeze the patch. When I reduced the number boxes, the patch started to be controllable up to the point of a complete problem solution. I had no idea it causes such problems. Anyone can confirm my observations?

    UPDATE:

    However, when I tried to use just a series of number boxes connected in serial fasion to the fast metro, it did not freeze the patch. Strange.

    posted in technical issues read more
  • Mr_Slow

    Oh, sorry. There are some abstractions in the patch that I forgot to deliver here. However, I believe they have no effect whatsoever on the perfromance of the patch. One is just a spigot object in an abstraction with some "fancy" GUI, another just a delay for a bang and the last just makes some midi note output.

    It is sufficient to run just the fastest metro in the patch and the patch freezes until it is stopped. Hope the patch is clear enough.

    posted in technical issues read more
  • Mr_Slow

    OK, here it is:

    #N canvas -4 -4 1826 1040 16;
    #X obj 799 324 bng 39 250 50 0 empty empty empty 17 7 0 10 -258113
    -1 -1;
    #X floatatom 966 448 5 0 0 0 - - -;
    #X floatatom 853 996 5 0 0 0 - - -;
    #X floatatom 853 926 5 0 0 0 - - -;
    #X msg 799 436 1;
    #X obj 842 1108 nbx 5 14 0 128 0 1 empty empty note 0 -8 0 10 -262144
    -1 -1 64 256;
    #X obj 881 1088 nbx 5 14 0 127 0 1 empty empty velocity 0 -8 0 10 -262144
    -1 -1 127 256;
    #X obj 920 1068 nbx 5 14 0 2500 0 1 empty empty nt_lenght 0 -8 0 10
    -262144 -1 -1 14 256;
    #X obj 929 1104 nbx 5 14 0 16 0 1 empty empty midi_ch 0 -8 0 10 -262144
    -1 -1 0 256;
    #X obj 853 1028 loadbang;
    #X obj 842 1129 abs_mknote;
    #X msg 282 558 const 0;
    #X obj 1058 649 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
    -1 -1;
    #X floatatom 1057 847 5 0 0 0 - - -;
    #X obj 1091 650 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
    -1 -1;
    #X obj 799 162 notein;
    #X obj 799 208 stripnote;
    #X floatatom 799 238 5 0 0 0 - - -;
    #X floatatom 886 237 5 0 0 0 - - -;
    #X obj 799 271 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
    -1 -1;
    #X obj 1587 492 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
    -1 -1;
    #X obj 1353 512 nbx 5 14 0 128 0 1 empty empty note 0 -8 0 10 -262144
    -1 -1 95 256;
    #X obj 1392 492 nbx 5 14 0 127 0 1 empty empty velocity 0 -8 0 10 -262144
    -1 -1 127 256;
    #X obj 1431 472 nbx 5 14 0 2500 0 1 empty empty nt_lenght 0 -8 0 10
    -262144 -1 -1 12 256;
    #X obj 1440 508 nbx 5 14 0 16 0 1 empty empty midi_ch 0 -8 0 10 -262144
    -1 -1 0 256;
    #X obj 1364 432 loadbang;
    #X obj 1353 533 abs_mknote;
    #X obj 1057 816 mod 4000;
    #X obj 1057 909 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
    -1 -1;
    #X obj 1057 879 sel 3999;
    #X obj 1380 68 tgl 35 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
    1;
    #X obj 1058 619 del 0;
    #X obj 1161 356 metro 300;
    #X obj 1159 557 sel 0;
    #X msg 1057 934 0;
    #X obj 1380 305 t i i;
    #X obj 1123 448 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
    -1 -1;
    #X obj 1156 447 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
    -1 -1;
    #X obj 1058 356 metro 1;
    #X obj 1353 351 i;
    #X obj 1353 263 delay 100;
    #X obj 943 373 abs_mujSpigot;
    #X obj 1605 375 abs_delvel;
    #X obj 1215 406 abs_mujSpigot;
    #X obj 1206 455 abs_mujSpigot;
    #X obj 1094 756 float;
    #X floatatom 1057 783 5 0 0 0 - - -;
    #X msg 1058 674 1;
    #X obj 1057 756 +;
    #X msg 1094 726 0;
    #X msg 1070 697 -1;
    #X text 1104 675 increment;
    #X text 1109 698 decrement;
    #X text 1132 724 reset;
    #X obj 281 641 table $0-notes 10000;
    #X obj 853 957 tabread $0-notes;
    #X obj 799 477 tabwrite $0-notes;
    #X text 887 713 counter --->;
    #X text 629 214 MIDI INPUT -->;
    #X obj 282 585 s $0-notes;
    #X text 378 556 <-- clear the table;
    #X obj 1009 1057 moses 1;
    #X obj 1076 1088 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
    -1 -1;
    #X text 1118 928 <-- stop the playback when a condition is met;
    #X text 1447 71 <--- RUN IT;
    #X text 1007 256 left metro goes through the table;
    #X text 954 284 right metro bangs some values into the table;
    #X text 687 374 custom spigot object -->;
    #X connect 0 0 4 0;
    #X connect 1 0 56 1;
    #X connect 2 0 61 0;
    #X connect 3 0 55 0;
    #X connect 4 0 56 0;
    #X connect 5 0 10 0;
    #X connect 6 0 10 1;
    #X connect 7 0 10 2;
    #X connect 8 0 10 3;
    #X connect 9 0 5 0;
    #X connect 9 0 6 0;
    #X connect 9 0 7 0;
    #X connect 9 0 8 0;
    #X connect 11 0 59 0;
    #X connect 12 0 47 0;
    #X connect 13 0 3 0;
    #X connect 13 0 1 0;
    #X connect 13 0 29 0;
    #X connect 14 0 49 0;
    #X connect 15 0 16 0;
    #X connect 15 1 16 1;
    #X connect 16 0 17 0;
    #X connect 16 1 18 0;
    #X connect 17 0 19 0;
    #X connect 19 0 0 0;
    #X connect 20 0 41 0;
    #X connect 20 0 26 4;
    #X connect 21 0 26 0;
    #X connect 22 0 26 1;
    #X connect 23 0 26 2;
    #X connect 24 0 26 3;
    #X connect 25 0 21 0;
    #X connect 25 0 22 0;
    #X connect 25 0 23 0;
    #X connect 25 0 24 0;
    #X connect 27 0 13 0;
    #X connect 28 0 34 0;
    #X connect 29 0 28 0;
    #X connect 30 0 33 0;
    #X connect 30 0 35 0;
    #X connect 30 0 40 0;
    #X connect 31 0 12 0;
    #X connect 32 0 37 0;
    #X connect 32 0 43 0;
    #X connect 33 0 14 0;
    #X connect 34 0 30 0;
    #X connect 35 0 39 1;
    #X connect 35 1 32 0;
    #X connect 37 0 44 0;
    #X connect 38 0 31 0;
    #X connect 38 0 36 0;
    #X connect 39 0 38 0;
    #X connect 40 0 39 0;
    #X connect 41 0 0 0;
    #X connect 42 0 20 0;
    #X connect 43 0 20 0;
    #X connect 44 0 42 0;
    #X connect 45 0 48 1;
    #X connect 46 0 27 0;
    #X connect 47 0 48 0;
    #X connect 48 0 45 0;
    #X connect 48 0 46 0;
    #X connect 49 0 45 0;
    #X connect 50 0 48 0;
    #X connect 55 0 2 0;
    #X connect 61 1 62 0;
    #X connect 62 0 10 4;
    

    posted in technical issues read more
Internal error.

Oops! Looks like something went wrong!