KVR: Forum Archive - ninja buffer message

KVR Forum [Instruments] » Archive » Instruments » January 2002 Index | KVRFA1

Author	Topic: ninja buffer message
exponent	Posted: 31st January 2002 23:39
	Well i was looking forward to using it but before loading the interface or channels in orion i get an error message about "ninja will only run with buffers of >4096, decrease the buffer size if possible" etc, then ninja dosent load and the whole host hangs.. Tried reducing my latency a couple times but it's still doin it and it makes me have to reboot so i quit tryin.. Using directX drivers here.. i've never gotten that message from freesonic, let alone any other vsti! Is anyone where i am at with this? Can anything be done about this technicality?
etherdesign	Posted: 1st February 2002 00:14
	I tested it in orion using a 1024 buffer on an ASIO (Echo Mia) card.. doesn't work.. Orion is pretty stringent about VST.. Halion and then FM7 didn't work until Rich released updates.. dunno if this is the same case.. it's a rather odd error message.. works a treat in Logic though, this is an amazingly featured VSTi for free.. the filters could be a bit better but the amount of parameters and the gui are great... if you're in a rock band it's probably useless, but for odd-sound lovers like me (who post-process their sounds anyway) it's a great palette of odd noises...
brittnell	Posted: 1st February 2002 02:39
	Ditto... I'm getting the same message, regardless of any changes made to either ASIO buffers or timebase settings (in Orion Pro 2.75). Brittnell
BONES	Posted: 1st February 2002 02:57
	At least you could get it to download. The link points to a file with a ".msi" extension that this MAC just reads as a big text file. Is it an EXE or a ZIP or what? [So I can rename it when I save.]
brittnell	Posted: 1st February 2002 03:48
	It's a Microsoft Installer format (self-extracting, self executing, etc.). Don't know how or if it'll run on a Mac. Bummer...
dusted william	Posted: 1st February 2002 03:52
	i'm getting the same problem. Too bad cause it looks cool. dw
morphlab	Posted: 1st February 2002 04:19
	this thing is gorgeous [ 01 February 2002, 07:30: Message edited by: meek ]
autodafe	Posted: 1st February 2002 11:51
	How do you change the buffer size in Logic???
jason	Posted: 1st February 2002 12:04
	quote: Originally posted by wakax: "cant do shit about that. if the plugin works with fixed buffers, its not fully VSTi-compliant. also, this would enforce (!!!!) lamest latencies." waks So I really want to know: how LARGE are the buffers inside ORION??? Ninja reacts to the setBlockSize() of the HOST application with this message. NINJA don't work with fixed buffers, but only with buffers lower than 4096 samples. So it is optimized for very short latencies... A modern VST host should support low latencies...
jason	Posted: 1st February 2002 12:53
	We could change this, but we want definitively to know: WHITCH BUFFER SIZE USES ORION OR FRUITY LOOPS DEFAULTLY? We have developed and tested only on the original Cubase host. We have not enought time to EXAMINE all available host applications... Cause we are part time developers (we have a completely other main job). We want some "support" by you experienced users! ps: a good idea would be to give us some registered host applications by the developers of these programms.
vbfischer	Posted: 1st February 2002 13:00
	quote: Originally posted by Autodafe: How do you change the buffer size in Logic??? You don't... Its a product of your soundcard. You need to change it in your Soundcard setup
jason	Posted: 1st February 2002 13:12
	As far as we know, every VST host application should have an ASIO control pannel. There you can edit the realtime possibilities of your host application by reducing the buffer sizes. If You use the shortest possible latencies and so the shortest rendering buffer sizes, so you should have full access to NIN!jA and best performance. We stress, NIN!jA is optimized for realtime usage on hq music host applications (especially for realtime playing with a master keyboard including velocity and channel aftertouch). Using with a slow Multimedia driver will not work properly, cause you cannot play NIN!jA in realtime then (too much latency).
autodafe	Posted: 1st February 2002 13:45
	To Bryce: Thx, I tried to adjust a setting in Logic which says "Larger Buffer Settings" but nothing changes...I'm at work now where I use the Built-in souncard for an Intel MotherBoard. I will try at home tonight to lower the settings of my Audiowerk8 (Which I think is set to 1024, btw) To Jason: Your work seems just wonderful, even if I couldn't hear it. People should think twice about complaining about a FREE VSTi . And I think that if a FREE thing doesn't work properly at first time, one shouldn't be so disappointed. I would complain about a NI product not working, not yours... About Logic or other platform compatibility: Isn't a Demo Version enough to test your plugins? There's a demo of Orion, Fruity and (i guess) a demo of Logic Audio... And if you don't have enough time to test ALL the different platform, why don't you send it out for some beta testing here on KVR? I volunteer for Logic Audio Keep up the good work. The demo song I've downloaded seems gorgeous...! [ 01 February 2002, 16:49: Message edited by: Autodafe ]
jason	Posted: 1st February 2002 14:25
	OK, I have updated the package now. Now you can change the buffer size of the host on the fly (no need to close and restart the host to get the NIN!jA working).
brittnell	Posted: 1st February 2002 14:28
	Hey Jason, First of all, thanks for the replies. I think something else is going on other than the ASIO buffer settings. I have tried adjusting mine (Terratec DMX 6-Fire 24/96) all the way from 2688 samples/buffer to 192 samples/buffer (which is 2msec latency at 96kHz, btw), all with no change in the nin!ja error message. I have also tried all of the timebase settings within Orion Pro, from 768PPQ to 96PPQ, with no luck. As for testing with the software, Sonic Syndicate ( www.sonic-syndicate.com ) has a great demo of Orion available, that I think should serve your testing needs. Please continue to dig into this and see if you can get it working for us Orion folk. Thanks, Britt -----edit----- ooops, looks like we were typing at the same time. I'll give the new version a shot right away. THANKS! [ 01 February 2002, 17:31: Message edited by: brittnell ]
jason	Posted: 1st February 2002 14:37
	I have tried it... I have a strange suspicion: ORION sends a initial call to the setBlockSize() function with a high buffersize... ...and this will "deceive" NIN!jA to switch it of!!! But I have to make an other try now....
nmarrone	Posted: 1st February 2002 14:46
	Hi jason, I'm really excited to use your softsynth, but because I use 98lite to install win98 I cannot install the .msi file. Is there any way I can get around this? Thanks, Feanor
topaz	Posted: 1st February 2002 14:49
	Orions demo (last time I looked) had no asio so it,s not that great.. quote: Originally posted by brittnell: Hey Jason, First of all, thanks for the replies. I think something else is going on other than the ASIO buffer settings. I have tried adjusting mine (Terratec DMX 6-Fire 24/96) all the way from 2688 samples/buffer to 192 samples/buffer (which is 2msec latency at 96kHz, btw), all with no change in the nin!ja error message. I have also tried all of the timebase settings within Orion Pro, from 768PPQ to 96PPQ, with no luck. As for testing with the software, Sonic Syndicate ( www.sonic-syndicate.com ) has a great demo of Orion available, that I think should serve your testing needs. Please continue to dig into this and see if you can get it working for us Orion folk. Thanks, Britt -----edit----- ooops, looks like we were typing at the same time. I'll give the new version a shot right away. THANKS!
jason	Posted: 1st February 2002 14:49
	Feanor: please mail me. Btittnell: No it dos'nt work. I fear Orion uses internally bigger (fixed)processing buffers and then accumulate it to the soundcards output... So not NIN!jA uses fixed buffers, but ORION!!! quote: "cant do shit about that. if the plugin works with fixed buffers, its not fully VSTi-compliant. also, this would enforce (!!!!) lamest latencies." it is not fair to call a plugin "not VST compilant", if the own host is'nt it... [ 01 February 2002, 17:55: Message edited by: jason ]
brittnell	Posted: 1st February 2002 14:51
	Weird... I'll write "around", and see what I can dig up.
jason	Posted: 1st February 2002 15:04
	We stress again: NIN!jA don't use fixed buffers. But "he" will not work with bigger buffer sizes, witch make impossible to play this synthesizer in realtime. This has also some performance reasons too...
brittnell	Posted: 1st February 2002 15:21
	Topaz: From Sonic-Syndicate.com: quote: Try before you buy The free trial versions have all the features of the registered versions - the only thing you can't do is save your songs or stream songs to a Wave file. We have not removed any of Orion's other features, so the trial versions should give you a very clear picture of Orion's unmatched creative potential! WAY back when, Orion did have an issue with ASIO support (in all versions, demo or otherwise), but that has since been completely fixed. It has been a while since I have used the demo of Orion, but I suspect from the statement above that the same ASIO support that current users enjoy will be in there for demo users as well.
impulse one	Posted: 1st February 2002 15:58
	Orion users: I suggest you download synthedit if you want to try ninja out... it works fine in that for me
jason	Posted: 1st February 2002 16:57
	quote: Originally posted by rezon8: jason- the specs on this project sound awfully close to a project you said you were working on in a thread awhile back about a Virus VSTi. is that the case? NO definitively not. The Virus is not decideble with this little tone generator called NIN!jA. "He" can only make a very deep bow in awe to the VIRUS! But there was nobody, who has shown any interest to realize an open source VIRUS...
jason	Posted: 1st February 2002 22:53
	I have tried a special compiling before a few minits to support the Orion users: I have increased the internal buffersize limitation to the double value (8192 samples) for a test. This is much more, than a realtime system should handle. But the result was the following: Orion don't accept it nevertheless. This is very crazy! How large buffers needs or calls ORION??? I fear this problem must be solved by the Orion coders... The internal realtime engine of the NIN!jA will not work properly wit such mega large buffer sizes. Sorry.
brittnell	Posted: 2nd February 2002 00:46
	Perhaps Orion simply will not work with a VSTi that is coded to have ANY sort of cap on buffer settings. I understand that this is normally left completely open, with these decisions made on the host end only (VST sdk). So it may not be that Orion uses a huge buffer (which I can tell you from long use that it doesn't), but rather that it doesn't like restrictions of any sort imposed from the VSTi end. Just grasping... ------edit------ perhaps, just as a final test, remove the internal buffer cap from the code completely, and see how it works. I often use Pentagon I (one of the more "demanding" VSTi's I have) with huge ensembles going at 96kHz and only 2ms latency within Orion (and no cracks). Remove the speed-bumps, and let me fly... [ 02 February 2002, 03:51: Message edited by: brittnell ]
jason	Posted: 2nd February 2002 16:59
	I had read a topic of the orion-central.com forum and can see, that the developer of Orion has a very "obstinate" interpretation of the setBlockSize() function (Steinberg VST SDK). Unfortunately this is very pity, because all other developers of host applications have obviously interpreted the usage of this function right. You can read our statement on orion-central.com.
al_iguana	Posted: 2nd February 2002 18:47
	Rich has replied to this on Orion Central. Please read it :/ i hope it gets sorted soon, i would love to use the Ninja. Al (i'm not a programmer or i would write my own)
jason	Posted: 2nd February 2002 19:43
	We are still thinking about a change of our coding, but my enthusiasm to do so is not very big now after the statements of the orion developers (it needs much time and it seems that we are not so important for Orion). A fact is simply, that the function call setBufferSize(long buffersize){} makes no sense, if a host sends a pure virtual value to this function on startup, witch is not usfull - like orion it does. The orion developer handels this function like a "orion internal used thing" witch has no significance to the processing plugin. THIS IS WRONG. If Orion would send the real used values for the size of the currently processed buffers, NIN!jA would work without any problems! So I think NOT our plugin is the problem... ps: all other hosts (the original VST host on the top) handle this function right. [ 02 February 2002, 22:46: Message edited by: jason ]
jason	Posted: 2nd February 2002 19:50
	We have not implemented this limitation, because we are "stupid beginners" or to shock some orion users. No, it has some important reasons for this.
MadGav	Posted: 2nd February 2002 20:33
	I have some sympathy for the developers on both side of this argument. The precise situation is the plugins are told a maximum buffer size by the SetBlockSize() call and should then process blocks of samples from 0 up this length (yes, I think Charlie Steinberg did say samplesFrames=0 was valid the other week, that would probably crash my plugs...). However, the fact that Orion is setting a huge buffer size of 32k samples seems extreme when it typically makes Process() calls with samplesFrames = ~167 samples! If a plugin allocates lots of buffers of blockSize this would waste a load of memory. If this is not technically _wrong_ behaviour it is at the least boorish. Martin (VAZ Designs)
al_iguana	Posted: 2nd February 2002 20:40
	We (Orion users) appreciate you taking the time to investigate this. Orion is the fourth most used sequencer : http://www.kvr-vst.com/oldpoll2.htm so it would be nice to be able to use it. who's to "blame" is irrelevant, really. Peace guys Al
al_iguana	Posted: 3rd February 2002 10:09
	yeah, its me, unfortunately speaking as a non-programmer, so my comment is useless really, but this topic has caused heated discussion, with all sorts of VSTi developers pitching in. where else would you find this? not in the "commercial" world, certainly. its good to see the community at work. better than a soap opera ok, you can return to more constructive comments now.. Al
Illusionist	Posted: 3rd February 2002 10:50
	I just want to say thanks to Jason for this freebie. I must say I wouldn't use it anyway, cause one big fault in Orion, IMHO. Since Ninja is multitimbral it opens up 16 mixerstrips in Orion. That's just unworkeable and I asked Richard to 'fix' this many times the last year (by givin the user the ability to add or delete mixerstrips), but it looks like Richard isn't bothered by this kind of problems. Too bad.
jason	Posted: 3rd February 2002 13:51
	Yes , too many mixer strips are a problem ever. Remember: Cubase too has a maximum VSTi output limitation. Initially we wanted to implement a full MIDI standard into NIN!jA(16 channels), but this would open 16 stereo outputs in the mixer of the host and so you cannot open other multitimbre synthesizers... Therefore NIN!jA has only 8 channels available. Of course, there is the possibility to realize an internal routing of the synthesizer outputs to only one or two final outputs, but we would support the wide open effect routing possibilities of the host applications for each synth (voice) channel, because NIN!jA has no internal effects. We found this is most creative.
MadGav	Posted: 3rd February 2002 18:57
	But Jason... taking your argument to it's logical conclusion surely you should just provide a monotimbral version? There is no advantage to multiple outputs unless you can combine stuff onto them (or leverage a condensed UI which makes sense for drumboxes). With a 1-1 synth-channel setup I'd rather load as many synths as I want and lose the problem. Martin [ 03 February 2002, 22:06: Message edited by: MadGav ]
jason	Posted: 3rd February 2002 19:27
	quote: Originally posted by MadGav: But Jason... taking your argument to it's logical conclusion surely you should just provide a monotimbral version? There is no advantage to multiple outputs unless you can combine stuff onto them (or leverage a condensed UI which makes sense for drumboxes). With a 1-1 synth-channel setup I'd rather load as many synths as I want and lose the problem. Martin No, I don't think so. - you have only one GUI with multitimbre - resources can be shared - performance is better, because the host has only to handle 1 synth and not 16 single synths - the workflow is much better with one synth instance - (much) less memory will be used - why go back in time to the 70th - and so on... For instance: Try to load 16 instances of the Pentagon1 into your memory and look, what it does. One Instance needs over 20 MB (megabyte) !! for a single timbre synthesizer. With a 16 channel NIN!jA you need only 1 MB and not 300 MB or so... Some people will have a very heavy and bad swap disk activity with this... But this may be a matter of taste... [ 03 February 2002, 22:32: Message edited by: jason ]
MadGav	Posted: 3rd February 2002 20:00
	[QUOTE]Originally posted by jason: - you have only one GUI with multitimbre - the workflow is much better with one synth instance This could be seen as a pro or con, depending on user preference. - resources can be shared This is easily done between multiple instances of a plugin loading in a host as global variables are process wide. - performance is better, because the host has only to handle 1 synth and not 16 single synths But by how much? You're losing some complexity in the plugin, gaining a little in the host. - (much) less memory will be used Only if the plugin makes large per instance as opposed to per timbre allocations, and as I pointed out before... For instance: Try to load 16 instances of the Pentagon1 into your memory and look, what it does. One Instance needs over 20 MB (megabyte) !! for a single timbre synthesizer. That sounds like a specific Pentagon issue (Rene?) With a 16 channel NIN!jA you need only 1 MB and not 300 MB or so... With all due respect your mental arithmatic sucks! On a positive note, a setup with several outputs useable as mix or aux buses could be even more efficient than what you have at present. The omnipresent effect on synths is reverb and that will probably be on a send anyway from the host channel strips. Martin
René	Posted: 3rd February 2002 20:47
	Hi all, I heard my bell ringing... quote: For instance: Try to load 16 instances of the Pentagon1 into your memory and look, what it does. One Instance needs over 20 MB (megabyte) !! for a single timbre synthesizer. With a 16 channel NIN!jA you need only 1 MB and not 300 MB or so... Some people will have a very heavy and bad swap disk activity with this... Memory usage has absolutely nothing to do with mono/multitimbrality. It is just a design decision. Pentagon I v1.2, which is already out to betatesters and will be released in few days, besides the new GUI and the ability of being user skinnable, will take 20 megs for first instance and only 4 megs for subsequent instances, while being monotimbral. How much memory the instrument use is also a decision... Pentagon I have 8 seconds of built-in stereo delay, 4 loadable waveforms (think of a loadable waveform as a sample) and that things...use your pc memory... fortunately. Regards, René
MadGav	Posted: 3rd February 2002 21:45
	quote: Originally posted by Al Iguana: We (Orion users) appreciate you taking the time to investigate this. Orion is the fourth most used sequencer : http://www.kvr-vst.com/oldpoll2.htm so it would be nice to be able to use it. who's to "blame" is irrelevant, really. Hi Al, I guess I recognise you from LJ? You know Juno, right? I wasn't going to get into flaming and blaming, although I do have some evidence that this is deserved because certain people think they are right when they are not and don't want to strike up a dialog with other developers. Martin
jason	Posted: 3rd February 2002 22:16
	quote: Originally posted by MadGav: Martin[/QB] Yes you have right (and I my silence). But I am a musican too and I work with VST instruments too... So you can believe me, I have thought about this before I have realized my own plugins. But my sight is a little bit different, that's all.

Forum topics in the archive are read only. New posts should be made in the main KVR Forums.

Disclaimer:
All communications made available as part of this forum and any opinions, advice, statements, views or other information expressed in this forum are solely provided by, and the responsibility of, the person posting such communication and not of kvraudio.com (unless kvraudio.com is specifically identified as the author of the communication).

User:	Pass: