So after some time off I am coming back to this now again and your midi recording nodes are still heavily in use and working flawlessly.
What’s not working flawlessly is my humble attempts at integrating sustain into it. Its working, but whenever sustain is on, everything just kind of starts stuttering. Do you have any idea what might be causing it? The basic logic of it is working, but the stuttering is strange. Its still not perfect, as there is no retriggering when sustain is on, so its not quite the same as what is happening in a piano yet.
Also I have another question. I would like to use a second instance of the recorder in another part of my patch. Basically I can either record the midi notes as they come in from the midi input and then do all the transformation OR I can do all the transformations to only the currently playing notes and then record only the transformations. I would like to have both versions in the patch.
So I simply added storage of matrix transforms to the data, but if I place the VL patch somewhere else, then that one doesnt do anything. All outputs are NIL all the time. So how can I place the same VL patch again, but as a separately working instance? It appears that it is different to how vvvv patches behave if you place them multiple times.
Hm, turns out it DOES work to place the same file twice. Not sure what I was doing before, but it seems to work now. It seems restarting vvvv is sometimes necessary after changes to the vl file.
ok, very good. and does the other problem with the stuttering now also work? i would need a v4 patch that isolates the problem as well to see what might be the problem…
@tonfilm - so I have isolated the relevant part, which shows the extreme slowdown of the midiStore VL node, as soon as Sustain is on. It doesn’t even have to have midi notes incoming and the debug timing goes from around 1000 to around 40000 with some fluctuation. Wether or not notes are being recorded actually doesn’t seem to make much difference.
I am thinking of rather than doing the sustain inside the midi recorder to already manipulate the midi data going into the recorder to observe sustain (ie. basically just holding all current and future notes till sustain is released). That way I can do that part in vvvv and not VL, which even after a lot of tinkering I simply dont “get” yet. Especially how documents work and are related to actual files is so confusing and unclear. I duplicated a VL file to edit a copy, but it took me so long to actually end up with 2 slightly different VL files that were linked to the proper file. Desperately need to come to Node for the VL workshops - whereas vvvv is already somewhat special in terms of usability, the VL editor takes it to a whole new level of unconventional UX.
Anyways, back to midi recorder. Here is a screenshot of the recorder during recording of some notes without sustain:
Attached is the basic setup to record midi and the .vl file.
Thanks so much for your help!
ps: I was looking for, but couldnt find the workshop schedule for Node 17. Now that we can buy Workshop tickets for specific days, dont we need the schedule? Maybe I just couldnt find it. Or could you just tell me when your VL workshops are?
thanks for taking the time to isolate the patch.
the change that made it so slow is this one:
do you need to record pitch and modulation per frame into each note? i did that in the recorder patch for demonstration purposes, but if you don’t need it it could be removed…
are you speaking about VL document handling and referencing them from vvvv files and other VL documents to use the nodes defined in them?
or do you mean how other files on hard drive can be found relative to a VL file?
are you speaking about VL document handling and referencing them from vvvv files and other VL documents to use the nodes defined in them?
or do you mean how other files on hard drive can be found relative to a VL file?
More about the first part. So if I have a node from a .vl file like the midi recorder: I open the file and save it as a different name, to have a copy that I can alter. Then I drag that in again and place one of the node from the new .vl file, but which is still identical. It seemed like I had to rename the nodes first, before I could actually have it reference the new file. But I guess its the same thing in vvvv - if you have several copies of a subpatch, then open one that you would like to change and save it as a different name, then all copies also reference the new name. So you have to do this weird thing where you copy everything, create a new patch, save it as a different name and place it again. In Grasshopper there is this great functionality called “Disentangle”, which makes an instance of a subpatch unique, without all the copy paste, save, drag in again thing. I am not aware of an easy way to do that in vvvv.
If I open a .vl document and save it as something else, shouldn’t it then reference that newly saved copy like with a subpatch? Because right now it doesn’t do that. Even if I drag in the newly saved copy into vvvv, it will then still reference the old copy and not the new one. So how can I duplicate a .vl file and place it into vvvv? What exactly has to be changed before it is recognized as a separate file?
Back to the midi recorder though:
The pitchbend and modulation part are needed and the weird thing is, that without the sustain the node has no slowdown, even though pitchbend and modulation should create much more overhead, since they record a value for every frame.
So something about sustain must be coded wrongly to cause such a dramatic slowdown, but I am not sure what it is.
Or are you saying that the combination of sustain and pitchbend and modulation is somehow causing the slowdown? I just dont get it though, all the sustain does is delay any note offs. Not sure why it would slow everything down like that.
i also did not understand it at a first look at it… but if you press sustain it will enable recording pitch/mod for EVERY note because of the link i showed you in the picture above. that might be all 128 not only the ones that are pressed? might that be the problem?
That sounds like it is most definitely the problem and would explain the sudden slowdown. Of course modulation and pitchbend should only be recorded for notes that are played. How can I change it so it works like that? So I need to somehow get sustain to be per note rather than a single variable!? Now that you said it, it actually makes sense, since sustain will trigger it for all notes, since its the same variable for all notes.
So the question is, how to make sustain stick for only notes that have been playing while sustain was pressed, plus all future notes that are pressed while sustain is pressed.
Just revisiting the midi recorder and after getting sustain working properly without hickups, I now noticed another thing that is not working correctly yet - the midi channels.
As you can see from my post from May 19, I am listening to all 16 channels, inputting a spread of 2048 notes and setting the bin size to 128 in the StoreMidiNotes VL node.
Somewhere in the VL logic the note number is mapped back down to the standard 128 and I cannot extract the channel any longer. So if for example I play a note on channel 2 of the midi device the incoming notespread might have a note playing at SliceIndex 192 - which would be note 64 on channel 2. But after it is stored it is now note 64, which would mean its playing on channel 1.
Is there a way to get back the channel information? How can I have the output notes retain their slice indexes? Any ideas?
I think it has to do with that Repeat Node. Does it even need that? As you can see I am converting Notes into the proper ranges and extracting the channel anyways outside of the recorder, so I dont mind if it outputs the same note range of 0 - 2048 as the input.
Just playing with the Notes Bin Size input and I dont think I understand it. It behaves normally up until 187, after that it goes all weird and at higher values the whole StoreMidiNotes just outputs Nil !?
hi @seltzdesign how about making an input for the channel number that you feed in an I (Spread) 0-15 and add that number to the note data.
also, the bin size output should have a slice count of 16 which tells you how many slices you have per channel. with that you can also find out the channel.
but i’d take option #1. add a property “Midi Channel” to the note data and feed the channel number with an I (Spread) into the VL node…
Hm, I think I understand and will try a few things. But more importantly I would like to understand how that Repeat node works in VL. How come I cant feed the recorder the whole notespread of 2048 nodes with a binsize of 2048 so I would get the note numbers as they come in. To calculate the channel from it you just divide by 128 and round to floor, which is super simple. Also to get the correct note number that is equally easy. That way no changes to the VL recorder would be necessary. The channel doesn’t have to be stored since its only calculated from the note anyways and I dont mind the notes being stored in the 0-2048 range.
But for some reason pushing the Notes bin size over 187 causes the node to output NIL. Why that number? Wouldnt setting the notes bin size to 2048 already do what I am after?
Now the notes are actually output as they come in, so note 187 is also stored as note 187, but the channel is still 0 in the channel output. Actually in the file you attached you are also using the note number to calculate the channel outside of VL, therefore the channel output is not needed in VL. Not sure why its not working though, since you divide the index by 128 and turn into an integer, which in the case of note 187 should be 1 and not 0 !?
You can use a simple SetSlice and Bang to simulate note 187 (ie. on Channel 2) and see whats happening.
So I think either it makes sense to calculate the corrected note number and channel in VL OR it doesn’t need the channel recording and just records the notes as they come in the 0-2047 range and calculating the correct note number and channel is done in vvvvv. I think the first would be nicer, since calculating the channel and calculating the corrected note number uses the same calculations and the channel and correct note numbers would be stored.
i don’t really understand the idea of outputting 2048 notes, because you want to record notes and that grows dynamically whenever you press a note… or not?
Thanks for the fix. I am just listening to 2048 potential notes. Of course I usually dont have just a keyboard connected, but a midi input from Ableton which has stuff sending on all 16 channels.
So if I have a channel output in the recorder, than the notes can also be from 0-128 again like they should. I was just using the note numbers from 0-2048 so I can calculate the channel myself.
ah, now i get it, yes that would also be possible. but sounds more like a hack, having data types makes that can have a property “Midi Channel” makes everything more clear i’d say. just takes some time to get used to.
Yes, I agree having the channel in the data type makes more sense.
So now I just noticed another thing with multi-channel recording though: Right now its only set up to work with 1 modulation, 1 pitchbend and 1 sustain. But it actually needs to work with a spread of 16 modulations, 16 pitchbends and 16 sustains (1 for each channel). So we need to check on what channel a mod, pb or sustain is coming in and only let it go through if the note being recorded is on the same channel.
Right now if there are notes coming in on several channels and there is a sustain coming in on channel 1, the node goes super slow, from ca 7000 ticks to 200000 ticks!
Huff, this is all zero problem in vvvv… but in VL… man, I really need to do some tutorials or something to understand how VL works… :/
Thanks for your help @tonfilm. Btw, is there a way we can hire you for a day?
i think that was solved already. are you sure the fix is still in place?[quote=“seltzdesign, post:39, topic:14561”]
Huff, this is all zero problem in vvvv…
[/quote]
i doubt that, dynamically recording arbitrary amounts of values per note is not even possible with vvvv unless you write a c# plugin…
there are tutorial videos online that explain all basics needed to understand the midi recorder patch…
