BrainModular

I've started dabbling with the SDK, and I'm still quite slow in C++ development, but I'm getting there....

As pointed out in other threads, the new scripting engine is lacking some features and seems to be a real CPU hog. I suppose it eventually will be optimized, but when Olivier will have the time and how much it can be optimized I guess noone can answer at time being. To me it seems that right now scripts should only be used in Hollyhock for simple stuff that isn't being executed very often.


I'm not sure whether I ever will bother to deal with UIs in the SDK, but I will rewrite some of the old scripts I've created through the years - escpecially MIDI related stuff. So I wonder which of my old scripts others would find it useful that I port to new user modules? I can't promise express delivery, but post your wishes here, and I see what I can do.

Cool
Your transpose and SustainEtc scripts are good candidate for me...

I would be highly interested in everything midi.

It's a bit sad to hear that the scripting is so badly performing in Hollyhock - I fear this will raise the bar for people against digging deeper into creating their own nodes. C++ for many is just too much and lacks the immediacy of changing something in a script and run it right away inside Usine.

In some cases it will be easier to load some midi VSTs like the pizimidi ones or the upcoming Loomer product that originally was intended to be called "Epoch" but is now looking for a new name. It sounds like a very deep implementation of a nodal midi system that could complement Usine quite nicely:
http://www.kvraudio.com/forum/viewtopic ... c&start=30
Scroll a bit down. Very musical ideas and a fully integrated LUA editor for scripts...

Add the currently very cheap Reaktor 5 (99.-) for sound creation and stay in nodal heaven all the time

My own AoN_Random C++ nodes are almost done, I just have to fix some refresh issues I don't understand yet to release a beta.

Cheers,

Tom

Yes, transpose and sustainEtc, I agree! The transpose was the smart one that sent the appropriate note offs, right? So you could transpose while playing.... that's so great.

Unfortunately, there was a bug in the old sustainEtc, and I had to stop using it. When I would lift the sustain pedal immediately after hitting a chord, it would cut off notes I was still holding down..... I don't know if it was due to processing latency in the script. It needed to be pretty immediate, but it happened to me regularly, so I stopped using it.

One feature I made a script for that sustainEtc doesn't do--I have a 'drone' switch that will keep currently held notes sounding, but ignores incoming notes, so you can set up an ambient wash or drone, and keep playing another sound source from the keyboard. When the switch is turned off, it sends the appropriate noteoffs to stop the drone. That might be a nice mode to add to sustainEtc, or perhaps better as a seperate script. The drone switch needs to be on its own input so you can keep using the sustain pedal normally while the drone is on.

Meanwhile, I'll look into epoch. I tried working with MIDI in Reaktor, and it's quite a pain having to do all the multiplexing and demultiplexing manually, unless there are some new (and more bug-free!) midi processing patches in the user library.....

I trust that hollyhock will continue to be optimized. Hopefully as fast as I can require it..... It seems to be very much on Olivier's radar. We'll see, as I haven't gotten to the point of doing anything to really stress it yet. And since V5 had audio dropouts on my computer when the CPU got above 3%, CPU numbers seem pretty meaningless to me now..... It does concern me to see 35% cpu when I haven't even done any audio processing yet, just experimenting with the new gui features. But olivier did say the gui will chew less when audio needs to happen.....

cheers,
-e

Well. I thought that transposing and sustain would be prime candidates, so I'm not surprised by the feedback so far...

When I get to it, I'll check for the bug with the cut off notes. The other drone idea sounds more like a temporary rerouting: hold chord, turn on switch and reroute incoming MIDI until switch is turned off, send noteoffs to stop drone. Am I getting it? If you could put up your script, it would help. And I agree - because of the rerouting/switching part, it seems more natural to have this as a separate module.

As to the bad performance of the scripting engine, I agree with Thomas. Going the SDK route is far more involved and complicated than scripting. I am a programmer myself that mostly write Oracle not-very-OO database stuff, so getting into C++ isn't exactly that simplest thing I've encountered with all its more or less cryptic ways.

You totally get it. I just realized I never did write the script. Just stopped the midi with a module. On the todo list.....

But yeah, turn off the midi, and send existing noteoffs later (for now, I just play the chord again, lame.)

I wonder if it would make sense (or be worth the time) to put in a different script engine, keeping the existing pascal one for backwards compatibility.

If you didn't need compatibility, maybe there would be some better options.... but that seems like a discussion for 6 months from now

+1 for everything midi.
I used piz midi plugs in 5.8 but in hollyhock I get save preset memory errors
So it might be time to stop using them. Although they have some features that are not avail in Usine.

woodslanding wrote:I wonder if it would make sense (or be worth the time) to put in a different script engine, keeping the existing pascal one for backwards compatibility.

I think this for sure - hook into python or lua and you get all those libraries others have written

+1 python

as it's so universal, widespread(as scripting language) , well documented and looked after.

Hi, I've finally finished (I hope) my first MIDI user module. I started with the recreation of the old Transpose script. I've included compiled versions for Win 43 and 64 as well as the source, so if anyone would try to compile on OSX that would be great.

Here it is: Transpose.zip

...andhere you'll find the Wiki.

seamus wrote:+1 for everything midi.
I used piz midi plugs in 5.8 but in hollyhock I get save preset memory errors
So it might be time to stop using them. Although they have some features that are not avail in Usine.

Yeah, it seems GUI-less VSTs don't save their settings correctly - it's the same if you copy and paste them, you lose the settings.
My guess is, that Usine just remembers the preset used, not the actual settings - and GUIless VSTs have none.
I filed a bug about it and hope it can be solved.

Bsork: good to see your progress! I'm currently into other work but will try to give those a try ASAP.

Cheers,

Tom

Just saw in the release notes that the next version number is now changed to [1.01.001] - so I guess it will be the initial release version?
And the notes seem to address these problems with presets/VSTs.

Cool,

Tom

great job Bsork, thanks+++

@thomas: your right, the next version will be the first official version.

bsork wrote:Hi, I've finally finished (I hope) my first MIDI user module. I started with the recreation of the old Transpose script. I've included compiled versions for Win 43 and 64 as well as the source, so if anyone would try to compile on OSX that would be great.

Here it is: Transpose.zip

...andhere you'll find the Wiki.

Nice work bsork, I look forward to testing it

I've not had chance to dig into the new SDK yet as I've just started a new job but as soon as life settles down I hope to start updating my old modules for Hollyhock.

caco wrote:... I hope to start updating my old modules for Hollyhock.

Looking forward to that!

@caco: top good news too!

bsork wrote:Hi, I've finally finished (I hope) my first MIDI user module.

how can i missed that !
well i know... to much work

congrats to our first user module for Hollyhock

i'll try to review your code 'when i'll have time' and provide some advice on the way to do things

Some one to compil it for Mac OSX ?

Is it an important work ?

cmodica wrote:Some one to compil it for Mac OSX ?

Is it an important work ?

Depends... You can do the same using standard Usine modules, but this module avoids hanging notes if you're playing and changing values at the same time.

Mmmm ... :/
Si it seems to be an important work .... I can't do it just by downloading a compiler software and clic somewhere ... :/

Another +1 for Python here.

If there is any change to the scripting language I'd vote for Lua - it's cross platform, computationally light and simple to learn

Sorry, but I had forgotten about the sustain thingie, so it has taken a bit more time than I thought. I first converted the old SustainEtc scipt to a user module before I found the bug Woodslanding mentions above. I decided to redo it almost from the ground up, and ended changing the functionality somewhat as well:

- I dropped the Hold2 mode as I didn't find it very useful.
- The sustain on/off is via a switch inlet, not a CC. This way it's easier to control on/off from some other logic in the patch, and you can use MIDI learn on a switch and change between latching/non-latching behaviour without changing anything on the MIDI controller.
- It's not foolproof so I added a panic button. I've managed to get both missing and stuck notes sometimes, but not when playing in a relatively "normal" way, only when banging away on the keyboard.

Download it here, and try it if you want. If you find a pattern in where the notes get stuck or hang, please tell.

A quick question: what is KA?

Also, I remember wishing before that I could set an upper and lower foldback point--0 and 127 are rather extreme! Maybe it could be the same as the note limit, but if you turn foldback on, it would use those values for the foldback point....

Anyway, it looks nice, and I'll try it out, thanks! I'll also see if I can track down the stuck notes in the hold module when I get a chance. My guess is that some of my playing looks like 'banging away' to usine!

cheers,
-e

A quick question: what is KA?

It's Key Aftertouch. More often called poly aftertouch, I think, but Usine uses key aftertouch, so so do I.

Also, I remember wishing before that I could set an upper and lower foldback point--0 and 127 are rather extreme! Maybe it could be the same as the note limit, but if you turn foldback on, it would use those values for the foldback point....

I definitely see your point. The 0~127 limit is more of a techicality than a creative option. I think adding a new pair of lo/hi foldback values would be the best solution.

Anyway, it looks nice, and I'll try it out, thanks! I'll also see if I can track down the stuck notes in the hold module when I get a chance. My guess is that some of my playing looks like 'banging away' to usine!

..or to my module... The way I keep track if which notes are sounding etc has been totally changed, so ample possibilities for new bugs.

I've uploaded a revised version of the Transpose user module. It has two new inlets for lo/hi limit for foldback function which previously only took care of notes transposed outside of the 0~127 range. Unlike the note lo/hi limit where you choose which notes to transpose and where lo can be more than hi leaving the middle unaffected, the foldback limits are more strict:

- If lo > hi, the values are ignored and the default 0 and 127 are used,
- If (hi - lo) < 12, octave foldback is ignored

BTW, for the foldback to kick in, the input notes must be within the transpose lo/hi limits, but there's no need to set a transpose value for it to work.