Jump to content


Photo

New Tool (3.0,3.1): xStream

live coding sandbox

  • Please log in to reply
131 replies to this topic

#126 joule

joule

    Guruh Motha Fakka is Levitating and Knows Everything About Renoise Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • 1444 posts
  • Gender:Not Telling
  • Location:Sweden
  • Interests:music, philosophy, engineering

Posted 09 August 2017 - 07:53

I have pretty much done what Oopslfly is talking about, but a bit more elaborate - passing each line notifier event thru a sandboxed function.

 

Be aware that the biggest obstacle when it comes to this kind of operation (track1+track2=track3), is that chances are very low that you'll get it working with pattern aliases. So the tool will never be perfect. This is for various design reasons (and bugs, I think) in the API. At least, that's my experience..



#127 danoise

danoise

    Probably More God or Borg Than Human Member

  • Renoise Team
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 6330 posts
  • Gender:Male
  • Interests:wildlife + urban trekking

Posted 09 August 2017 - 12:11

chances are very low that you'll get it working with pattern aliases. So the tool will never be perfect

 

Don't forget that matrix slots can be aliased as well. It's all very tricky in the detail, but possible.

Don't know what bugs you are referring to? 


Tracking with Stuff. API wishlist | Soundcloud


#128 joule

joule

    Guruh Motha Fakka is Levitating and Knows Everything About Renoise Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • 1444 posts
  • Gender:Not Telling
  • Location:Sweden
  • Interests:music, philosophy, engineering

Posted 09 August 2017 - 12:21

There are several issues regarding pattern aliases. I've tried to explain it in a previous thread, but it's a bit difficult. http://forum.renoise...dex-observable/

 

Short story:

 

1) Keeping track of all aliases is generally quite tricky (but possible).

2) alias_pattern_index_observable will bang when a sequence is removed. This should be a bug, or at the very least a design flaw.

3) alias_pattern_index_obserfvable will bang when a sequence is inserted. So, yet more work-around logic is needed to circumvent this, if it's even possible.

 

Eventually, you'll find that you have to use lots of workarounds and complicated schemes. Everything would have been solved with some simple change in the API itself. So.. the motivation you're left with after trying, is only enough for writing a crappy forum post about it :)


Edited by joule, 09 August 2017 - 12:21.


#129 danoise

danoise

    Probably More God or Borg Than Human Member

  • Renoise Team
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 6330 posts
  • Gender:Male
  • Interests:wildlife + urban trekking

Posted 09 August 2017 - 12:51

I've tried to explain it in a previous thread

 

Hey man, thanks. That's a constructive post you made there...good points.

You should've expected at least *some kind* of response for that. For me, it somehow slipped under the radar. 

 

And while I'm personally not afraid to implement workarounds, I agree that anything that can't be done cleanly/properly needs a critical examination. 


Tracking with Stuff. API wishlist | Soundcloud


#130 OopsIFly

OopsIFly

    Guruh Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPip
  • 857 posts
  • Gender:Male
  • Interests:...daydreams... -VS- ...propaganda...

Posted 09 August 2017 - 16:04

Oh, it's not a bug, it's a quirk then - if with clever filtering and double checking every relevant event can be collected somehow, then things are finde with me. Ofc I can understand its problematic if you don't know the whereabouts, and also think that a proper api that don't need quirkyness workarounds is the best, but well, in my experience almost any complex software api has such strange behaviour somewhere in its guts.

 

Hm, so I thought I'd first do the processing code until it works fine. It would also set me going as I could compose a tune straight or with some native groove, and then experiment with grooves, single-run applying them on command. This would also be useful for old (quasi finished) tunes, that are to get some a posteriori ants into their pants...

 

Then I thought about an event catcher func that is as slim as ever possible, just filtering/collecting relevant events to some stack or so. Then a processing routine that goes in the background that will apply the action - is the idle notifier background threaded, or would I have to split the workload in packets for the whole thing not to block the engine at any point more than absolutely nessecary? Is it generally advisable to put processing out of the notifier handlers and schedule into idle routines instead?

 

I mean also, the nature of the task I have in mind is very simple, and with the right concept it could work out well. I don't know how robust I would want to make this. For example the effected copy of a track is never to be touched by the user, I'd for example go for assuming the user not to touch it and periodically and by demand overwrite whatever crap happened to the track just to make sure. Maybe the processing also can be kept rather simple, by for example always processing the whole patterntrack on a change instead of trying to weed out just single notes that were changed. I will also try looking for nudge/shift tools, or similar, to lend some note overlap handling for shifting notes to (new) columns. My main concern on the live grooving approach is to keep it, for the user, as close to a normal workflow as possible, I have some Ideas going on about this. But some concepts will imply my own preffered workflow I think, or also have to add quite some visible baggage to the project in order for it to work nicely.

 

Maybe you want to split the discuss to another thread as its not related to your tool any more. I also have to say there will be some time passing until I can try working on this. Might have to wait for nothern hemisphere winter... I am no seasoned programmer, just an enthusiast, and I have other things to waste my time with, and want to get warm with another tool that aims accelerating sample creation/editing/processing workflow with the convolver first.



#131 joule

joule

    Guruh Motha Fakka is Levitating and Knows Everything About Renoise Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • 1444 posts
  • Gender:Not Telling
  • Location:Sweden
  • Interests:music, philosophy, engineering

Posted 09 August 2017 - 16:21

In this case, using an idle notifier/process slicer is not necessary if you have a fairly fast processor IMO. I'd say go for a simple approach - you can always add such things later on if really needed. It's more sensible to first focus on optimizing any .song() access, as this often will suffice.

#132 danoise

danoise

    Probably More God or Borg Than Human Member

  • Renoise Team
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 6330 posts
  • Gender:Male
  • Interests:wildlife + urban trekking

Posted 10 August 2017 - 11:05

Then I thought about an event catcher func that is as slim as ever possible, just filtering/collecting relevant events to some stack or so. Then a processing routine that goes in the background that will apply the action - is the idle notifier background threaded, or would I have to split the workload in packets for the whole thing not to block the engine at any point more than absolutely nessecary? Is it generally advisable to put processing out of the notifier handlers and schedule into idle routines instead?


When you're processing a whole song, or basically anything that takes enough time that a script timeout could happen (a dozen seconds or so), you can "slice" your process.
This is similar to a thread (co-routine), and really isn't that hard to implement. It's just a matter of creating a self-contained method that does the processing and periodically hands over time to the main process via a yield(). Here is a working example:
https://github.com/r...cedProcess.xrnx

 

Maybe you want to split the discuss to another thread as its not related to your tool any more. I also have to say there will be some time passing until I can try working on this. Might have to wait for nothern hemisphere winter... I am no seasoned programmer, just an enthusiast, and I have other things to waste my time with, and want to get warm with another tool that aims accelerating sample creation/editing/processing workflow with the convolver first.

 

You'll probably want to create a topic once the tool takes shape, but having it here for now is fine with me  :)


Tracking with Stuff. API wishlist | Soundcloud






Also tagged with one or more of these keywords: live coding, sandbox